使用ASP.NET MVC进行项目组织的最佳实践

Question

我最近下载了Rob Conery的优秀ASP.NET Storefront reference application并且发现它非常有启发性。我想到的一个问题是，应该放置Model类（以及它们所依赖的Data类）。 MVC项目模板创建一个Model文件夹。但在我看来，我会更好地将模型分解为一个单独的项目组件，以便其他潜在的应用程序（例如与网站的应用程序域相关的管理工具）可以重复使用它？

我很想得到别人的意见。

Answer 1

这实际上取决于项目的规模。拥有单独的“模型”程序集没有内在价值，因为您可以对Web应用程序项目（包括MVC项目）进行单元测试。

Answer 2

我同意。除非应用程序只是单个Web应用程序，否则我会将其分解为单独的项目。通常我会有一个Web应用程序前端，它使用一个或多个Windows服务来执行重复的自动化任务（提交费用，发送通知等）和一个或多个控制台应用程序工具来从我们的企业目录中配置应用程序用户群 - 我的应用程序通常是内部网应用程序，可能只适用于我们整个用户群的子集。将模型（数据层）放在一个单独的项目中，可以让我轻松地与所有其他应用程序共享它。

Answer 3

我喜欢为我的模型，数据访问和业务逻辑提供单独的项目。我在每一层都有接口。这使得使用模拟测试变得简单，保持我的代码组织并使我的控​​制器保持轻盈。如果我将所有图层放在模型文件夹中，那对我来说就不够整齐（只是个性化的事情）。我也希望能够为我的应用程序公开Web服务，这样就可以为这些服务提供所有相同的逻辑，模型和数据访问。

Answer 4

如果您的模型是域传输对象，那么将它们放在一个单独的程序集中将允许您重用它们。如果您的应用程序是一个简单的MVC应用程序，并且就是它的全部内容，或者您​​只是进行单元测试，则不需要它。否则你可以：

• 您是否有Web服务层使用模型程序集将模型对象传递给mvc应用程序以在您的应用程序中使用。如果您不允许Web应用程序直接访问数据库，则需要这样做。在这种情况下，您可能有一个调用Web服务的mvc来验证和提取数据。

• 您打算使用相同的模型构建其他应用程序，例如您提到的管理工具。

我希望有所帮助。另外，您可能希望将“常见”部分放在自己的框架中，其中包括“模型”（实体，域对象，您喜欢的任何名称）。

Answer 5

有时在MVC网站项目中有一个Models文件夹并且有一个单独的项目来存储数据模型也许是有意义的。 （尽管如果你有一个非常大的平台，你正在使用其他项目重用公共库，这可能才有意义。）

示例如下：

项目：

• CrossCutting：包含在其他服务之间传输数据对象的所有通用接口，以及与安全相关的操作和类

• 业务：包含业务层对象和操作，通过安全需求控制对操作的访问（仅使用CrossCutting接口输入和输出）。

• 数据：包含用于访问其他服务/数据库数据的模型（由Business项目使用）

• WebAPI :( MVC项目）包含Models文件夹。一些模型对象可能是CrossCutting接口的组合，以支持最高效的RESTful Web操作（因此，单个HTTP调用Web API但可能导致多个BLL调用）。

Answer 6

单独的组件！=松耦合。