ASP.NET MVC解决方案的组织

Question

5

我想创建一个相当大规模的ASP.NET MVC项目，希望将其分解成不止一个项目和一个程序集。我看了一下Oxite的组织方式（http://oxite.codeplex.com/Wiki/View.aspx?title=architecture），但我想知道其他人是如何做的。有什么建议吗？

目前，我正在考虑与Oxite非常相似的东西：

Project - 该项目包含模型层，其中包括模型、配置类和服务和存储库的接口。这里应该没有太多的应用逻辑，主要是数据结构。

Project.Core - 该项目包含所有控制器和路由的代码，包括过滤器和结果。还包括视图数据模型。

Project.Site - 该项目包含视图、图像、JavaScript和所有其他静态非代码文件。这里应该有最少的C#代码，大部分应该位于Project.Core中。

- ajma

2个回答

2

这是我们分解项目的方式。这个ASP.NET MVC项目已经快要发布了，我们也从中学到了一些东西。我也会给出每个项目单独存在的原因。

Project.Models - MVC中的M，包含所有业务类。如果你能做到（你真的应该），这里不应该有任何持久化或Web服务相关的类。当然，你可以在这个项目中定义数据访问接口。检查这个项目是否“干净”的一个快速方法是检查这个项目是否需要对数据访问DLL（如NHibernate）进行引用。

原因：理论上，即使你切换到其他UI，比如控制台等，你也应该能够打包这个项目并在任何其他地方使用这些类。

Project.Site - 这个项目包含所有JavaScript、CSS、View等与视图相关的内容。

原因：如果你有一个网站设计师，你可以直接让他/她访问这个项目并让他/她工作。

Project.Controllers - MVC中的C，包含所有控制器和ModelBinders。

原因：将模型、视图和控制器分成三个不同的项目可以更好地避免关注点泄漏。

Project.Tests - 将所有单元测试放在单独的项目中可以迫使你只测试公共接口；这是我个人认为很好的单元测试实践。

Projects.Services - 所有Web服务、持久化相关代码都在这个项目中。

目前，任何实用程序类都放在Project.Models中，但我认为最好有一个单独的解决方案来处理实用程序类，并在需要时将它们作为已编译程序集的引用导入。

- Praveen Angyan

我不建议将视图和控制器放在不同的项目中。它们都非常具体且相互配合。最好将它们放在一个项目中。 - harsimranb

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bramha Ghosh · Accepted Answer

您可能希望查看S#arp Architecture如何将控制器、服务和核心拆分为项目，并配套测试项目。