ASP项目组织的最佳实践。净MVC[关闭]

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

我同意。除非这个应用程序只是一个web应用程序,否则我会把它分解成一个单独的项目。通常情况下,我会有一个web应用程序前端,它使用一个或多个windows服务来执行重复操作,自动化任务(提交费用、发送通知等)和一个或多个控制台应用程序工具,以从我们的企业目录中提供应用程序用户群——我的应用程序通常是内部网应用程序,可能只适用于我们整个用户群的子集。将模型(数据层)放在一个单独的项目中可以让我轻松地与所有其他应用程序共享。

我喜欢为我的模型、数据访问和业务逻辑制定单独的项目。我在每一层都有接口。这使得模拟测试易于实现,使我的代码井然有序,控制器轻巧。如果我把所有的图层都放在models文件夹中,我会觉得它不够有条理(只是一个个性的东西)。我还希望可以选择为我的应用公开web服务,这样就可以为这些服务提供所有相同的逻辑、模型和数据访问。

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

• 让web服务层使用模型组件将模型对象传递给mvc应用程序,以便在应用程序中使用。如果你练习不允许网络应用直接访问数据库,就需要这样做。在这种情况下,您可能有一个调用web服务的mvc来验证和提取数据。

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

我希望这能有所帮助。另一方面,您可能希望将“公共”部分放在自己的框架中,其中包括“模型”(实体、域对象,以及您喜欢的任何名称)。

有时,在MVC网站项目中有一个Models文件夹,并有一个单独的项目来存储数据模型可能是有意义的。(不过,只有当你有一个相当大的平台,并且你正在与其他重用公共库的项目一起工作时,这才有意义)。

下面是一个例子:

项目:

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

• 业务:包含业务层对象和操作,通过安全需求控制对操作的访问(仅使用横切接口进行输入和输出)。

• 数据:包含用于从其他服务/数据库访问数据的数据模型(由业务项目使用)

• WebAPI:(MVC项目)包含一个Models文件夹。一些模型对象可能是横切接口的组合,以支持最高效率的RESTful web操作(因此,对web API的单个HTTP调用可能会导致多个BLL调用)。

单独的组件!=松耦合。