我是一名Java开发人员，正在向C＃世界过渡。我已经对ASP.NET MVC有了很好的处理（并且可以将它与我为Struts学习的概念进行比较/对比）。
但是，我正在寻找有关如何构建项目的建议。目前，我在项目中有两个解决方案：MVC Web应用程序和ClassLibrary部分。
该应用程序使用分层架构：控制器/服务/ DAO。为了使工作“正确”，我在MVC解决方案中有Controller和Model类，在ClassLibrary解决方案中有Services，DAO和Security。不幸的是，这导致了各种各样的小问题（例如：当我尝试在MVC端扩展它以进行表单验证时，从ClassLibrary端的Entity Framework扩展UserAccount对象是不明确的。）
我能想出的唯一解决方案是将所有内容放入MVC项目中，并在App_Code文件夹下组织当前ClassLibrary中的内容。它会解决一些问题，但对我来说似乎是“错误的”;我的Java项目将代码分成src目录，并将视图（jsp）分成ta webapp目录。
一些经验丰富的.NET开发人员会怎么想？
答案 0 :(得分：3)
通常在.NET解决方案中，最好的办法是只在代码可能对其他应用程序有用时，或者代码本身代表某个问题域的完整解决方案时，才将代码分成不同的项目。仅由一个应用程序项目引用的类库是一种浪费。
另外，请记住.NET不允许两个不同程序集中的对象之间的循环引用（通常与项目一对一翻译）。
在您的示例中，我建议您考虑模型，服务和安全性的一个类库...取决于您在说“服务”时的含义。
在大多数情况下，数据访问在某种程度上与MVC模型的概念相关联，因此您可能会考虑将数据访问放在那里......但如果您有一个非常干净的数据访问层，它可能适合它自己的班级图书馆。
控制器和视图通常应直接进入Web项目。
一般来说，我的建议是，只有当你有实际的“需要”时才将东西分成不同的项目。但是，在大多数应用程序中，程序集和项目不是表示层或层的好方法。这些逻辑概念并不总能很好地映射到物理项目结构。
如果你很好地设计你的实际类并避免紧耦合，你通常可以在以后出现真正引人注目的需求时将代码移到类库中。
答案 1 :(得分：0)
让事情“正确”是什么意思？我发现只需在web.config的命名空间导入部分中包含命名空间即可解决大多数问题。执行此操作时，其他程序集中的模型将自动解析，并在MVC对话框中显示，在编码视图时显示在intellisense中。