是否有针对 ASP.NET MVC 生产应用程序的建议解决方案结构

Question

一般来说，我不喜欢将代码（BaseClasses 或 DataAccess Code）保存在 ASP.NET 站点的 App_Code 目录中。我通常会将这些东西分别放入 MySite.BusinessLogic 和 MySite.DataAccess DLL 中。

我想知道我是否应该为 ASP.NET MVC 做同样的事情。

按照以下方式组织解决方案会更好吗

• MySite.Common - DLL -（基于 .NET 系统 Dll 构建的基本功能）
• MySite.DAL - DLL -（DataAccessLayer 和 DBML 文件）
• MySite.Models - DLL -（MVC 模型，例如存储库类）
• MySite.Controllers - DLL（使用模型的 MVC 控制器）
• MySite - ASP.NET MVC 站点。

或者我是否遗漏了一些东西......大概，我会失去一些不错的东西（添加视图、转到控制器、已添加的上下文菜单项）

Answer 1

我只使用 MVC 完成了几个项目，但使用您的命名结构我们做了以下事情：

• MySite.Common - DLL -（基于 .NET 系统 Dll 构建的基本功能）
• MySite.DAL - DLL - (DataAccessLayer & DBML 文件和存储库模型）
• MySite.Models - 将其作为一部分包含在内 的 MVC Web 应用程序，只有 特定于视图的模型 始终为每个映射一对一 存储库模型。
• MySite.Controllers - 作为一部分包含 的 MVC 应用程序，但可以链接到业务层
• MySite - MVC 应用程序。

所以最后在我的 MVC 解决方案中有以下项目：

• MVC Web 应用 - 包含将 DAL 数据映射到的控制器、视图模型。
• 通用 - 可在其他应用中使用的功能
• DAL - 包含所有与数据访问相关的数据，包括包装类
• BL - 可选，具体取决于是否需要大量业务特定逻辑
• 测试

编辑：我的 DAL 总是输出包装的对象（如果使用 Linq2Sql，那么我将自动生成的类直接映射到我在 DAL 中的类）。 MVC 应用程序中唯一存在的类是代表视图的容器，主要用于将数据传递给视图。

如果您的移动应用使用类似的视图，我不会尝试从您的 MVC 应用视图中重复使用相同的类。您总是需要管理一些细微的差异，并且您应该能够只使用 DAL 类来映射到您的移动视图，这遵循将视图类本地化到应用程序的模式。

Answer 2

在大多数情况下，以下结构可以正常工作：

• MySite.BusinessLogic（控制器、模型、存储库等）
• MySite.BusinessLogic.Tests（控制器、模型、存储库等的单元测试）
• MySiteA（视图、静态内容）
• MySiteB（视图、静态内容）

MySiteA 和 MySiteB 可能是从业务逻辑重用功能的同一站点的两种风格。

从性能的角度来看，您应该更喜欢更少的大型程序集而不是许多小型程序集。

Answer 3

我们做的事情有点不同

• [数据库名称].Database.DLL（特定数据库的 DBML 文件）
• [数据库名称].Services.[问题域].DLL（包含模型、服务和存储库）
• [数据库名称].Services.[问题域].Tests.DLL
• [数据库名称].Services.DLL（当上述所有内容都很好地适合单个服务项目时）
• [数据库名称].Services.Tests.DLL
• [问题域].Services.DLL（问题域的业务逻辑）
• [问题域].Services.Tests.DLL
• Web.Framework.DLL（可重用的 ASP.NET 和 MVC 组件）
• Web.Framework.Tests.DLL
• MySite.Web.DLL（包括 ViewModel 的 MVC 应用程序）
• MySite.Web.Tests.DLL

我们这样做是因为我们有多个要连接的数据库和数据服务。并且根据问题领域的不同，可能会使用不同的模型集访问同一数据库，但有时会共享相似的名称。

在服务模块中，我们将具有以下结构

• \型号
• \存储库
• \服务
• \等