4

通常，我不喜欢将代码（BaseClasses 或 DataAccess 代码）保留在 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 站点。

或者我错过了什么......大概，我会失去一些好的（添加视图、转到控制器、已添加的上下文菜单项）

4

3 回答 3

3

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

  • MySite.Common - DLL -（基于 .NET 系统 Dll 构建的基本功能）
  • MySite.DAL - DLL - (DataAccessLayer & DBML Files and Repostiory Models)
  • MySite.Models - 将此作为 MVC Web 应用程序的一部分包含在内，并且仅具有特定于视图的模型，这些模型并不总是为每个存储库模型一对一映射。
  • MySite.Controllers - 作为 MVC 应用程序的一部分包含，但可以链接到业务层
  • MySite - MVC 应用程序。

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

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

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

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

于 2010-03-25T16:50:59.087 回答
3

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

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

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

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

于 2010-03-25T17:39:03.020 回答
2

我们做的事情有点不同

  • [数据库名称].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

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

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

  • \楷模
  • \存储库
  • \服务
  • \ETC。
于 2010-03-25T18:33:13.313 回答