我是一名 Java 开发人员，正在过渡到 C# 世界。我已经很好地掌握了 ASP.NET MVC(并且可以将其与我学到的 Struts 概念进行比较/对比)。
但是，我正在寻求有关如何构建我的项目的建议。目前，我的项目中有两个解决方案:MVC Web 应用程序和 ClassLibrary 部分。
该应用程序使用分层架构: Controller /服务/DAO。为了让事情“正确”地工作，我在 MVC 解决方案中添加了 Controller 和模型类，在 ClassLibrary 解决方案中添加了服务、DAO 和安全性。不幸的是，这导致了各种小问题(例如:当我尝试在 MVC 端扩展 UserAccount 对象以进行表单验证时，从 ClassLibrary 端的 Entity Framework 扩展 UserAccount 对象是不明确的)。
我能想到的唯一解决方案是将所有内容放入 MVC 项目中，并组织当前在 App_Code 文件夹下的 ClassLibrary 中的内容。它可以解决一些问题，但对我来说似乎“错误”；我的 Java 项目将代码分离到 src 目录中，将 View (jsp)分离到 webapp 目录中。
一些经验丰富的 .NET 开发人员有何看法？
最佳答案
通常，在 .NET 解决方案中，最好的选择是将代码分离到不同的项目中，前提是该代码可能对其他应用程序有用，或者代码本身代表某些问题域的完整解决方案。只被一个应用程序项目引用的类库是一种浪费。
此外，请记住，.NET 不允许两个不同程序集中的对象之间进行循环引用(通常与项目进行一对一转换)。
在您的示例中，我建议您考虑为模型、服务和安全性使用一个类库...具体取决于您所说的“服务”时的含义。
在大多数情况下，数据访问在某种程度上与 MVC 模型的概念耦合，因此您可能会考虑将数据访问也放在那里......但如果您有一个非常清晰地分离的数据访问层，它可能适合它的自己的类库。
Controller 和 View 通常应该直接进入Web项目。
一般来说，我的建议是仅当您确实“需要”时才将内容拆分为单独的项目。但程序集和项目并不是在大多数应用程序中表示层或层的好方法。这些是逻辑概念，并不总是能很好地映射到物理项目结构。
如果您很好地设计了实际的类并避免了紧密耦合，那么当确实出现真正迫切的需求时，您通常可以稍后将代码移至类库中。
关于asp.net-mvc - ASP.NET MVC 应用程序结构的建议，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2024196/