我以前从未使用过MVC设计模式，最近我开始使用ASP.NET MVC开发项目。
我正在使用ActiveRecord作为我的数据层。
我也使用视图模型（每个视图都是唯一的）和AutoMapper将我的视图模型映射到EntityFramework实体。
在几天内研究MVC，EntityFramework和阅读不同的文章我想出了以下设计：
在我的解决方案中，我有Web项目（表示层），其中包含视图和控制器。
我有Core项目，我定义了我的ViewModels和服务（所有业务逻辑都在的业务层）
我有EntityModels项目，所有我的EF实体都存在（数据层）
这种设计允许我将我的数据层与我的表层分开，Web项目对EntityModels项目一无所知，反之亦然，所有逻辑都存在于业务层。
从我的控制器（验证检查后）我将viewModels传递给Service层，在那里执行映射和所有必要的busines逻辑。
这个设计是否正确？
我的观点是，我已经读过ViewModel应该在Presentation Layer中定义。我看到了Presentation Layer对数据层的引用和映射是在控制器中完成的示例（良好实践？）。在这种情况下，控制器将域模型传递给业务层。我没有任何经验，但我不喜欢它。
那么，任何人都可以指出我在哪里以及哪里出错了吗？
提前感谢。
答案 0 :(得分：2)
整体而言，架构看起来不错。在我看来，关于在何处放置视图模型的决定取决于一个因素。
您是否计划将来有其他客户可以从重用这些视图模型（iPad，Android等）中受益？
如果是这样，一定要将它们从MVC组件中取出并放入自己的组件中。否则，只要您在移动它们并更改代码（如果您决定建立第二个客户端）时，您就可以安全地将它们放入MVC应用程序中。
为了记录，我总是把我的视图模型放在他们自己的程序集中。它不需要花费更多的时间，但如果事情发生变化，它会带来红利。
答案 1 :(得分：0)
FWIW，我正在做同样的事情 - 但我是MVC的新手，所以不是100％肯定我也在正确的道路上。但是，它只是“感觉正确”，这通常告诉我这是正确的。 我唯一要补充的是我使用的是automapper（automapper.org），这几乎消除了拥有图层的开销。绝对检查IMO。 我不得不说，唯一没有100％正确感觉的是，使用这种模式，我们创建了大量的ViewModels - ＆gt;每个视图一个。我假设您的意思是每个域实体EACH的创建，索引，更新，详细信息都有自己的ViewModel？或者你在视图之间共享一个ViewModel？ 最后，我不买jfars的论点，它创造了很多复杂性/构建时间。至少，它在概念上将层次分开得更多。让我感到更好的是分离问题，而且开销很小 我有一个重复使用视图模型进行Silverlight实现的梦想，但还没有真正想到的那个。但是有意义的是，如果你把所有“非UI”代码分解到视图模型和服务中，那么做一个新的UI应该是“微不足道的”，对吧？我们会看到： - ）