ASP.NET MVC 生产应用是否有建议的解决方案架构？

Question

ASP.NET MVC 生产应用是否有建议的解决方案架构？

asp.net-mvcprojects-and-solutionsstructurecode-organizationsolution

4

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

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

是否最好按以下方式组织解决方案：

- MySite.Common - DLL - （基于.NET System Dlls构建的基本功能） - MySite.DAL - DLL - （数据访问层和DBML文件） - MySite.Models - DLL - （MVC模型，例如存储库类） - MySite.Controllers - DLL - （使用模型的MVC控制器） - MySite - ASP.NET MVC网站。

还是我漏掉了什么...大概会失去一些已添加的好用的（Add View、Go To Controller、上下文菜单项）吧。

- Eoin Campbell

3个回答

3

在大多数情况下，以下结构表现良好：

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

MySiteA和MySiteB可能是同一站点的两个版本，重用业务逻辑的功能。

从性能角度考虑，您应该优先选择较少的大型程序集，而不是许多小型程序集。

- Darin Dimitrov

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（包括ViewModels的MVC应用程序）
MySite.Web.Tests.DLL

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

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

\Models
\Repositories
\Services
\等等。

- Todd Smith

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

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

- Kelsey · Accepted Answer

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

MySite.Common - DLL - （基于.NET系统DLL构建的基本功能）
MySite.DAL - DLL - （数据访问层和DBML文件以及存储库模型）
MySite.Models - 将其包含在MVC Web应用程序中，并且仅具有特定于视图的模型，这些模型并不总是一对一地映射到每个存储库模型。
MySite.Controllers - 包含在MVC应用程序中，但可以链接到业务层
MySite - MVC应用程序。

因此，在我的MVC解决方案中有以下项目：

MVC Web应用程序 - 包含控制器，视图模型来映射DAL数据。
Common - 可在其他应用程序中使用的功能
DAL - 包含所有与数据访问相关的数据，包括包装类
BL - 根据需要进行选择，如果需要大量业务特定逻辑则选择此项
Tests

编辑：如果使用Linq2Sql，则我的DAL始终输出包装对象（然后将自动生成的类映射到DAL中的类）。在MVC应用程序中存在的唯一类是表示视图的容器，主要用于向视图传递数据。

如果您的移动应用程序使用类似的视图，则不要尝试重用MVC应用程序视图中的相同类。始终存在轻微差异，您需要进行管理，您应该能够仅使用DAL类来映射到移动视图，这遵循将视图类本地化到应用程序的模式。