我正在尝试使用 MVC。我来自 ASP.Net 背景。
创建新的 mvc 3 应用程序后，我在同一个 webapp 项目下获得了控制器、模型和视图。在 ASP.Net 中，我们通常为模型和控制器创建单独的项目（我假设它们与业务层相同）。我还为 DAL 创建了一个单独的项目，我将在其中使用 EF。
我很困惑，这是理想的解决方案结构吗？我们不应该为每一层创建单独的项目吗？由于我将 DAL 作为一个单独的项目创建，因此我必须在其中添加 WebApp 的引用，因为我想从 DAL 返回模型，因此现在我无法将 DAL 的引用添加到我的 WebApp。
有人可以说明我在这里缺少什么吗？我做的不对吗？
【问题讨论】：
标签： c# asp.net-mvc architecture
MVC 确实将“M”部分留给了开发人员。
即使在他们的官方示例中，您也会看到变化。您的问题暴露了对 MVC 最常见的误解之一。你不应该将你的域或数据模型直接绑定到视图，你的控制器方法也不应该接受它们作为参数。见this post on over and under-posting。
理想情况下，您的控制器将调用 DAL，并且某些机制会将这些数据或域模型映射到视图模型。 WebApp“Models”文件夹中应该存在的正是那些 View 模型（专门用于促进 UI 的模型）。
因此，您创建一个包含 DAL 的新程序集肯定是在正确的轨道上。映射到 ViewModel 的“最简单”机制之一是每个 ViewModel 上的简单方法：
public class MyWidgetFormModel()
{
public string Name { get; set; }
public string Price { get; set; }
public MapFromDAL(DAL.Widget widget)
{
this.Name = widget.Name;
this.Price = widget.Price;
}
}
更新：根据您的 cmets，here is an excellent answer 关于一位用户的项目布局。
【讨论】：
当我开始使用 MVC 时，我遵循了 Jeffrey Palermo 洋葱架构。你可以阅读它：
这里：http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
这里：http://jeffreypalermo.com/blog/the-onion-architecture-part-2/
这里：http://jeffreypalermo.com/blog/the-onion-architecture-part-3/
它使用 IoC 支持来解耦服务。我认为您应该考虑使用 IoC 容器，因为 MVC 架构是围绕使用 IoC 的模式来考虑的，以便解耦服务（层）。
您还可以使用洋葱架构从http://codecampserver.codeplex.com/ 下载工作示例。
它不是您可以与 MVC 一起使用的唯一架构，但它是一个很好的起点，可以帮助您了解 IoC 和 MVC 应用程序中的解耦。
【讨论】：