在ASP.NET MVC中将实体映射到模型并执行业务逻辑

Moh*_*and 9 architecture asp.net-mvc n-tier-architecture

将数据库实体映射到模型和执行业务逻辑的最佳实践是什么?我已经看到两者的实现差异很大.我注意到了许多实现,其中Repository(在数据层中)本身负责将数据库实体映射到域模型.例如,一个可以执行此操作的存储库:

public IQueryable<Person> GetPersons()
{
      return DbSet.Select(s => new Person
                    {
                        Id = s.Id,
                        FirstName= s.FirstName,
                        Surname= s.Surname,
                        Location = s.Location,
                    });
}
Run Code Online (Sandbox Code Playgroud)

但是在N Tier设计上全面搜索SO时,我注意到虽然没有银弹,但在大多数情况下,建议手动或使用Mapper在MVC项目中执行控制器内的映射.还有人重申,服务层永远不应该执行映射,并且它应该负责执行业务逻辑.这里有几个问题:

  1. 关于将实体映射到模型的位置,建议采用哪种方法,反之亦然?存储库应该执行此操作还是应该在控制器中完成映射?
  2. 假设我想对我从数据库中检索的实体执行一些业务逻辑,例如,返回Personenities 的全名,或者将所有Persons 的年龄增加10年,应该在哪里执行此操作.在模型本身?例如,我会FullName在模型上有一个属性来计算全名和年龄吗?或者我在服务层内定义一些服务来执行业务逻辑?

编辑

哇这么多亲密的选票.道歉,我没有全面搜索.我在这里提出的"在哪里执行业务逻辑"问题已经可以在SO和其他地方找到(虽然有时会有些隐晦地传达):

由Stephen Walther通过服务层进行验证

瘦的控制器

关于SO的另一个伟大但更通用的答案

我应该在哪里将我的控制器业务逻辑放在MVC中

服务是否将实体映射到视图模型

但是我还没有找到我所遇到的映射问题的标准解决方案,而且我想我也许可以更有说服力地表达我的问题.因此,普遍的共识似乎是业务逻辑进入服务层,将域模型映射到视图模型应该在控制器/表示层中进行.并且由于建议不要将数据库实体映射到数据层以外的任何层,因此建议您手动或通过映射器(如Auto Mapper)将实体映射到数据层的域模型(这是我从阅读很多文章).我的困惑源于将实体映射到域模型以及将域模型映射到视图模型的问题.然而,正如我之前提到的,我可以更清楚地表达我的问题.我混淆的原因是我已经读过,映射实体到域模型应该在控制器中发生,这应该改为说"将实体映射到域模型应该在以后的数据中发生,并将域模型映射到视图模型应该在控制器中进行.

Big*_*ddy 4

  1. 对于将实体映射到模型的位置以及反之亦然,哪种方法是可取的?存储库应该执行此操作还是应该在控制器中完成映射?

我强烈希望看到映射发生在存储库中,而不是控制器中。正如 Suhas 在他的回答中提到的那样,控制器需要纯粹充当协调员。作为替代方案,也许您可​​以利用存储库中的映射类来传递实体并返回映射模型 - 有点像Auto Mapper

  1. 假设我想对从数据库中检索到的实体执行一些业务逻辑,例如返回 Person 实体的全名,或者将所有 Person 的年龄增加 10 年,这个操作应该在哪里执行。就模型本身而言?例如,我在模型上是否有一个 FullName 属性来计算全名和年龄?或者我是否在服务层中定义一些服务来执行业务逻辑?

如果可能,请在服务上执行业务逻辑。为什么要让应用程序承担服务层应该做的事情呢?我相信这是服务的域,而不是应用程序的域。另外,我也不认为从模型返回串联或派生属性是一件坏事。

概括:

  • 控制器处理来自视图的请求并将它们转发到存储库
  • 存储库是通往数据存储的渠道
  • 服务处理来自存储库的请求、处理业务逻辑并返回映射模型