关于ASP.NET MVC应用程序结构的建议

Question

我是一位正在向C＃世界过渡的Java开发人员。我已经对ASP.NET MVC有了很好的处理（并且可以将它与我为Struts学到的概念进行比较/对比）。

但是，我正在寻找关于如何构建我的项目的建议。目前，我在这个项目中有两个解决方案：MVC Web应用程序和一个ClassLibrary部分。

该应用程序使用分层架构：控制器/服务/ DAO。为了让事情“正确”工作，我在MVC解决方案中有Controller和Model类，在ClassLibrary解决方案中有Services，DAO和Security。不幸的是，这导致了各种小问题（例如：当我试图在MVC端进行表单验证时，将ClassAibrary对象从实体框架扩展到ClassLibrary端时是不明确的）。

我唯一能提出的解决方案是将所有东西放入MVC项目中，并组织App_Code文件夹下的ClassLibrary中的内容。它会解决一些问题，但对我来说似乎是“错误的”;我的Java项目将代码分隔成一个src目录，并将视图（jsp）分离到ta webapp目录中。

一些更有经验的.NET开发人员会怎么想？

Answer 1

通常在.NET解决方案中，最好的办法是将代码分离到不同的项目中，但前提是该代码可能对其他应用程序有用，或者代码本身代表某个问题域的完整解决方案。仅由一个应用程序项目引用的类库是浪费。

另外，请记住，.NET不允许在两个不同程序集（通常与项目一对一转换）中的对象之间循环引用。

在你的例子中，我建议你考虑模型，服务和安全性的一个类库......这取决于你说“服务”时的意思。

在大多数情况下，数据访问与MVC模型的概念有些耦合，因此您可能会考虑将数据访问也放在那里......但是如果您有一个非常干净的独立数据访问层，它可能适合它是自己的类库。

控制器和视图一般应直接进入Web项目。

一般来说，我的建议是只有当你有一个实际的“需要”这样做时，才能将东西分成单独的项目。但是程序集和项目并不是在大多数应用程序中表示图层或层的好方法。这些逻辑概念并不总是很好地映射到物理项目结构上。如果你真的很好地设计你的实际类并避免紧密耦合，那么如果确实会出现真正令人信服的需求，通常可以将代码移入类库中。

Answer 2

通过使事情“正确”工作意味着什么？我发现大多数问题都可以通过在web.config的命名空间导入部分简单包含命名空间来解决。当你这样做时，来自其他程序集的模型会自动解析并显示在MVC对话框中，而在编码视图时会显示在intellisense中。