3

我以前从未使用过 MVC 设计模式，最近我开始使用 ASP.NET MVC 处理项目。

我使用 ActiveRecord 作为我的数据层。

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

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

在我的解决方案中，我有包含视图和控制器的 Web 项目（表示层）。

我有核心项目，我在其中定义了我的 ViewModels 和服务（所有业务逻辑所在的业务层）

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

这种设计允许我将我的数据层与我的表示层分开，Web 项目对 EntityModels 项目一无所知，反之亦然，所有逻辑都存在于业务层中。

从我的控制器（在验证检查之后）我将 viewModels 传递到服务层，在该层执行映射和所有必要的业务逻辑。

这种设计完全正确吗？

我的担心是我已经读过 ViewModels 应该在表示层中定义。我看到了表示层引用数据层并且映射是在控制器中完成的示例（好的做法？）。在这种情况下，控制器将域模型传递给业务层。我在这里没有任何经验，但我不喜欢它。

那么，谁能指出我哪里对，哪里错？

提前致谢。

4

2 回答 2

3

总体而言，架构看起来不错。在我看来，决定在哪里查看模型取决于一个因素。

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

如果是这样，请务必将它们排除在 MVC 程序集中并将它们放入自己的程序集中。否则，如果您决定创建第二个客户端，只要您可以移动它们并更改代码，您就可以安全地将它们放入 MVC 应用程序中。

作为记录，我总是把我的视图模型放在他们自己的程序集中。前期不需要更多时间，但如果事情发生变化，它会在未来产生红利。

于 2011-07-12T16:36:45.497 回答
1

FWIW，我也在做同样的事情——但我是 MVC 的新手，所以不能 100% 确定我也走在正确的道路上。但是，它只是“感觉正确”，这往往告诉我它是正确的。我唯一要补充的是我使用 automapper (automapper.org)，它几乎消除了拥有层的开销。一定要看看IMO。我不得不说，唯一感觉不是 100% 正确的是，使用这种模式，我们正在创建大量的 ViewModel -> 每个 View 一个。我假设您的意思是每个域实体的创建、索引、更新、详细信息每个都有自己的 ViewModel？还是您在视图之间共享一个 ViewModel？最后，我不购买 jfars 的论点，即它会产生大量的复杂性/构建时间。至少，它在概念上将层分离得更多。
我有一个将视图模型重用于silverlight实现的白日梦，但还没有真正想到这一点。但是如果你很好地将所有“非 UI”代码分解到视图模型和服务中，那么做一个新的 UI 应该是“微不足道的”，对吗？走着瞧 ：-）

于 2011-09-16T00:26:04.557 回答