使用EntityFramework和映射的ViewModel的ASP.NET MVC最佳实践

Question

我之前从未使用过MVC设计模式，最近开始使用ASP.NET MVC工程。

我的数据层使用ActiveRecord。

我还使用视图模型（每个视图都有唯一的视图模型）和AutoMapper将我的视图模型映射到EntityFramework实体。

经过几天的研究MVC、EntityFramework并阅读不同的文章，我提出了以下设计：

在我的解决方案中，我有一个Web项目（展示层），其中包含Views和Controllers。

我有一个核心项目，在这里定义我的ViewModels和Services（业务层，所有业务逻辑都在此处）。

我有一个EntityModels项目，所有EF实体都在其中（数据层）。

这种设计使我可以将数据层与展示层分离，Web项目不知道EntityModels项目的任何信息，反之亦然，所有逻辑都在业务层中。

从我的控制器（经过验证检查）传递ViewModels到Service层，在那里执行映射和所有必要的业务逻辑。

这个设计正确吗？

我的担忧是，我读到过ViewModels应该在Presentation Layer中定义。我看到了一些例子，其中Presentation Layer引用Data layer，并在控制器中进行映射（好习惯？）。在这种情况下，控制器将领域模型传递给业务层。我在这方面没有任何经验，但我不喜欢它。

那么，有人能指出我哪里做得对，哪里做得错吗？

提前感谢。

- Burjua

Answer 1

整体架构看起来很好。在我看来，关于将视图模型放置在何处的决定取决于一个因素。

您是否计划未来有其他客户端可以受益于重用这些视图模型（iPad、Android等）？

如果是这样，一定要将它们保留在MVC程序集之外并放置在它们自己的程序集中。否则，只要您愿意在以后决定制作第二个客户端时移动它们和更改代码，就可以将它们放在MVC应用程序中。

记录上，我总是将我的视图模型放在它们自己的程序集中。这不会在前期花费更多时间，但如果事情发生变化，它会带来回报。

- Craig M

---

是的，我所有的视图模型都在自己的命名空间下的单独程序集中。 - Burjua

@jfar 构建时间，认真吗？你用什么恐龙机器编码？不冒犯，但我完全不同意你的评论。添加一个额外的程序集并构建时间非常短暂，特别是对于将保存简单视图模型的程序集，似乎你正在寻找反对此答案的理由。如果您在构建过程中没有几秒钟的空闲时间，那么您的操作肯定有严重问题。 - Craig M

@Craig M，每天构建数百次时，每增加一秒钟都很重要。 Projectitus是一种非常糟糕的行为，它在没有有效物理原因的情况下为每个小事情创建一个项目（与创建文件夹相比仅有的原因），你会减缓构建时间，而这仅仅是为了未来节省15分钟的罕见机会。 不值得。 - John Farrell

假设“每天建造数百次”相当于最少200次，那意味着在一天8小时内你每2.4分钟建造一次，或者你夸大了。我同意一些开发者拥有项目过度症，而我不喜欢这种做法，但像模型这样对系统来说非常核心的部分肯定值得单独组装。 - Craig M

Answer 2

顺便说一下，我正在做同样的事情 - 但我是MVC的新手，所以不确定是否正确。但是，它只是“感觉对了”，这往往告诉我它是正确的。 唯一要补充的是，我使用automapper（automapper.org），它几乎消除了具有层的开销。在我看来，一定要检查它。 我必须说，唯一感觉不完全正确的是，使用此模式，我们正在创建大量的ViewModels->每个View一个。我假设您的意思是每个域实体的Create、Index、Update、Details都有自己的ViewModel？还是在视图之间共享一个ViewModel？ 最后，我不认同jfars的论点，即它会创建大量的复杂性/构建时间。至少，在概念上更加分离了这些层。它给我留下了更好地分离关注点的印象，开销非常小。
我有一个梦想，可以重用viewmodels进行silverlight实现，但还没有真正考虑过这个问题。但是，如果您成功地将所有“非UI”代码因素化为viewmodels和服务，则应该很容易完成新的UI，对吧？我们拭目以待 :-)

- Joe

---

抱歉，刚刚重新阅读了您的问题，您已经在使用automapper了 - 我很抱歉。 - Joe