我正在寻求创建一个相当大规模的 ASP.NET MVC 项目，我想将其分解，以便它不是全部在一个项目和一个程序集中。
我查看了 Oxite 如何在他们的组织 (http://oxite.codeplex.com/Wiki/View.aspx?title=architecture) 中开展工作，但我想知道其他人也是如何做到的。有什么建议吗？
目前，我正在考虑与 Oxite 非常相似的东西：
项目 - 该项目包含模型层，其中包括模型、配置类以及服务和存储库的接口。这里应该没有太多的应用逻辑，主要是数据结构。
Project.Core - 该项目包含控制器和路由的所有代码，包括过滤器和结果。这里还包括 ViewData 模型。
Project.Site - 该项目包含视图、图像、javascript 和所有其他静态非代码文件。这里应该有最少的 C# 代码，大部分应该放在 Project.Core 中
【问题讨论】：
标签： asp.net-mvc s#arp-architecture
您可能想查看S#arp Architecture 如何将其控制器、服务和核心拆分为具有相应测试项目的项目。
【讨论】：
以下是我们拆分项目的方式。这个 ASP.NET MVC 即将推出，我们在此过程中学到了一些东西。我已经给出了每个项目独立的原因。
Project.Models - MVC 中的 M，它包含您所有的业务类。如果您可以管理它（您确实应该），那么这里应该没有持久性或与 Web 服务相关的类。您当然可以在此项目中定义用于数据访问的接口。检查此项目是否“干净”的数据访问的一种快速方法是检查您是否需要在此项目中引用 NHibernate 等数据访问 DLL。 原因：理论上，您应该能够捆绑该项目并在其他任何地方使用这些类，即使您切换到不同的 UI，如控制台等。
Project.Site - 这个项目包含你所有的 JavaScript、CSS、View 等，以及与 View 相关的所有内容。 原因：如果你有一个网站设计师，你可以让他/她访问这个项目并让他工作。
Project.Controllers - MVC 中的 C，它包含所有控制器以及 ModelBinders。 原因：模型、视图和控制器的三个不同项目使得关注点泄漏更难发生。
Project.Tests - 将所有单元测试保存在单独的项目中会迫使您只测试公共接口；我认为单元测试的好习惯。
Projects.Services - 所有 Web 服务，与持久性相关的代码都在这个项目中。
目前，任何实用程序类都进入 Project.Models，但我认为为实用程序类提供单独的解决方案并在需要时将它们作为对已编译程序集的引用导入会更好。
【讨论】：