2013-01-09 36 views
7

将数据库实体映射到模型并执行业务逻辑的最佳实践是什么?我已经看到了两个不同的实现。我注意到了一些实现,其中Repository(在数据层中)本身负责将数据库实体映射到域模型。例如,一个存储库这样做:将实体映射到模型并在ASP.NET MVC中执行业务逻辑

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

不过话说搜索全面周围SO N个双层设计,我注意到,虽然没有银弹,在大多数情况下,这是最好的内部执行映射MVC项目中的控制器手动或使用Mapper。还有人重申,服务层不应该执行映射,并且应该负责执行业务逻辑。这里有几个问题:

  1. 哪种方法对于将实体映射到模型以及反之亦然是可取的?存储库应该这样做还是应该在控制器中完成映射?
  2. 假设我想对从数据库中检索到的实体执行一些业务逻辑,例如返回Person实体的全名,或者将所有Person的年龄增加10年,应该在何处操作被执行。在模型本身?例如,我会在模型上有一个FullName属性来计算全名和年龄?还是我在我的服务层中定义一些服务来执行业务逻辑?

编辑

哇这么多的接近票数。道歉,我没有足够全面的搜索。我在这里提出的“在何处执行业务逻辑”的问题已经可以在SO和其他地方发现的(虽然有时有点传达含糊):

Validating with a Service Layer by Stephen Walther

Skinny Controllers

Another great, but more generic answer here on SO

Where Should I put My Controller Business Logic in MVC

Does a Service Map Entities to a View Model

但是我还没有找到标准的解决方案来解决映射问题,而且我想我可能更加雄辩地表达了我的问题。因此,普遍的共识似乎是业务逻辑进入服务层,并且将域模型映射到视图模型应该发生在控制器/表示层中。由于不建议将数据库实体映射到数据层以外的任何层,因此建议您将实体映射到数据层的域模型,可以手动或通过映射器(如Auto Mapper)进行映射(这是我从中收集的阅读很多文章)。我的疑惑出现在将实体映射到域模型和映射域模型以查看模型的位置的问题。不过,正如我之前提到的,我可以更清楚地表达我的问题。造成混淆的原因是我已经阅读过映射实体到域模型应该发生在控制器中,这应该改为说:“将实体映射到域模型应该在稍后发生在数据上,并且映射域模型以查看模型应该发生在控制器中

回答

4
  1. 哪一种方法是在问候哪里实体映射到 车型为宜,反之亦然?存储库是否应该这样做,或者应该在控制器中完成映射吗?

我强烈希望看到映射发生在存储库而不是控制器。控制者需要像Suhas在他的回答中提到的那样纯粹作为协调员。作为替代方案,也许你可以利用在经过实体的存储库中的映射类,并返回一个映射模型 - 一种像Auto Mapper

  • 假设我要执行一些业务例如,我从 已从数据库中检索到的实体的逻辑,返回人名enity的全名 ,或将所有人的年龄增加10年, 应在何处执行此操作。在模型本身?对于 示例我将在模型上有一个FullName属性,它将计算全名和年龄?或者我在服务层 内定义一些服务来执行业务逻辑?
  • 如果可能,请在服务上执行业务逻辑。为什么要将应用程序的负担放在服务层应该做的事上?我相信这是服务的领域,而不是应用程序的。另外,我不认为从模型返回串联或派生的特性也是一件坏事。

    摘要:

    • 控制器从视图处理请求,并将其转发到 库
    • 库是管道到您的数据存储
    • 服务从仓库处理请求,处理业务逻辑, 并返回映射模型
    1

    我通常在MVC项目中创建一个小的服务层来处理MVC层需要完成的额外工作。因此,在您的示例中,您可以使用PersonServicePersonHandler调用业务层,以获取所有人员实体,然后将所有人员的年龄增加10年(假设这不是业务逻辑,而只是UI需求),连接名字和姓氏以建立全名等等。然后控制器调用这个服务并且不知道幕后发生了什么。通过这种方式,您的控制器正在做它理想的工作 - 在视图和模型之间进行协调。

    1

    这取决于... 就像你说的那里不是银弹。人们只能列出每种方法的优点和缺点,但仍然是你比其他任何人更了解你的要求。 如果您有时间,建议您阅读本书Patterns of Enterprise Application Architecture。这将使您很好地理解不同的业务逻辑和数据源架构模式,以及何时和如何使用它们。业务层应该发生什么以及DAL应该发生什么。 此书还解决了如何从DAL映射到域实体的问题。从长远来看,你甚至可以改变你的想法并选择完全不同的方法。

    还可以考虑使用一些ORM,它为您提供了像EF First First或NHibernate这样的Code First机制。在这种情况下,所有的映射逻辑对你来说都是透明的。

    1

    数据访问层(存储库)应该只处理插入/更新/检索您的数据实体。 您的服务层处理业务逻辑并负责您的表示层(控制器,视图模型)和您的数据层之间的通信。这意味着你从数据实体到域的转换应该发生在这一层。 您的表示层(控制器)应处理视图模型和域模型之间的转换。 - 如果您希望有更好的理解,您应该考虑Maksym的建议和选择企业应用程序体系结构的模式(以及其他许多人)将Fowler视为Web应用程序开发的权威。另一本好书是ASP.NET设计模式,它基于福勒的书,但只专注于ASP.NET框架。