我最近下载了Rob Conery的优秀ASP.NET Storefront reference application，我发现它具有令人难以置信的启发性。想到的一个问题是应该放置Model类（以及它们所依赖的Data类）的位置。 MVC项目模板创建一个Model文件夹。但是在我看来，将模型分解成单独的项目组合可以更好地服务于其他潜在应用程序（例如与网站应用程序域相关的管理工具）。使用ASP.NET MVC进行项目组织的最佳实践
我很好奇想得到人们的意见。
这真的取决于项目的规模。单独测试一个Web应用程序项目（包括MVC项目）时，没有单独的“模型”程序集的内在价值。
我同意。除非应用程序只是一个单一的Web应用程序，否则我会把它分解成一个单独的项目。通常，我将有一个Web应用程序前端，它使用一个或多个Windows服务来执行重复的自动化任务（提交费用，发送通知等）以及一个或多个控制台应用程序工具，以从我们的企业目录供应应用程序用户基础 - 我的应用程序通常是内联网应用程序，可能仅适用于我们整个用户群的子集。将模型（数据层）放在单独的项目中，可以让我轻松地将其与所有其他应用程序共享。
如果您的模型是域转移对象，那么将它们放在单独的程序集中将允许您重用它们。如果你的应用程序是一个简单的MVC应用程序，这就是它的全部，或者你只是做单元测试，这是不需要的。否则，你可以：
有你的Web服务层使用模型组件模型对象传递到MVC应用程序在应用程序中使用。如果您练习不允许Web应用程序直接访问数据库，则需要这样做。在这种情况下，您可能会有一个调用Web服务来验证和提取数据的mvc。
您打算使用相同的模型构建其他应用程序，例如您提到的管理工具。
我希望有帮助。在附注中，您可能想将自己的“常见”部分放在您自己的框架中，其中包括“模型”（实体，域对象，您喜欢的任何名称）。
独立组件！=松耦合。
我喜欢为我的模型，数据访问和业务逻辑分开项目。我在每一层也有接口。这使得模拟测试很容易实现，保持我的代码组织，并保持我的控制器光。如果我将所有图层放在模型文件夹中，它对我来说就不够整齐（只是个性化的东西）。我也喜欢为我的应用程序公开Web服务的选项，所以这使得所有这些服务都可以使用相同的逻辑，模型和数据访问。
有时在MVC网站项目中有一个Models文件夹并且有一个单独的项目用于存储数据模型也是有意义的。 （尽管如果你有一个非常大的平台，你正在与其他项目重用公共库一起工作，这可能只有意义）。
一个例子是这样的：
项目：
交叉性：包含其他服务，以及与安全相关的业务和类
之间的所有transfering数据中的公共接口的对象周围业务：包含业务层对象和操作，通过安全需求（仅使用CrossCutting接口输入和输出）控制对操作的访问。
数据：包含数据模型的其他服务访问数据/数据库（由业务项目使用）
的WebAPI：（MVC项目）包含一个型号的文件夹。一些模型对象可能是CrossCutting接口的组合，以支持最高效的REST风格的Web操作（所以，单个HTTP调用Web API，但可能导致多个BLL调用）。
但包含在一个没有帮助，不是吗？ – 2008-11-09 04:33:41