MVC：库和服务 [英] MVC: Repositories and Services

问题描述

我很困惑，在库被定义什么，什么留下来服务的限制。如果只有库创建简单的实体从数据库匹配的表，也可以创建复杂的自定义对象与这些实体的组合？

换句话说：应该将服务进行各种LINQ到SQL查询的信息库？还是应该所有的查询中的 predefined 的在库和业务逻辑简单地决定调用哪个方法？

解决方案

您实际上已经提出了在这里的一个问题，因此目前产生了很多的讨论，在开发者社区 - 参见后续意见的如果我的仓库暴露的IQueryable

存储库可以 - 也应该 - 创建一个包含多个关联实体的复杂组合的对象。在领域驱动设计，这些被称为聚集 - 组织成一些有凝聚力结构有关对象的集合。您code没有叫 GetCustomer（）， GetOrdersForCustomer（）， GetInvoicesForCustomer（）单独 - 你只需要调用 myCustomerRepository.Load（客户ID），你得到一个深刻的客户对象，已实例的属性。我还要补充一点，如果你根据特定的数据库表返回单个对象，那么这是一个非常有效的方法，但它不是真正本身的资源库的 的 - 它只是一个数据访问层<。 / p>

一方面，有一个令人信服的说法，LINQ到SQL对象，用自己的智能特性及其延迟执行（即不加载Customer.Orders，直到你真正使用它）是的一个完全有效的实现资料库模式，因为你没有实际运行的数据库code，你正在运行LINQ语句（然后由底层的LINQ提供程序翻译成DB code）

在另一方面，马特布里格斯'后指出，L2S是相当紧耦合到您的数据库结构（每个表一个类），并有一定的局限性（无多对多的映射，例如） - 你可能会更好关闭使用L2S为您的存储库中的数据访问，但然后映射L2S对象到您自己的域模型对象，并返回这些。

I am confused as to the limitations of what gets defined in the Repositories and what to leave to the Services. Should the repository only create simple entities matching tables from the database or can it create complex custom object with combinations of those entities?

in other words: Should Services be making various Linq to SQL queries on the Repository? Or should all the queries be predefined in the Repository and the business logic simply decide which method to call?

解决方案

You've actually raised a question here that's currently generating a lot of discussion in the developer community - see the follow-up comments to Should my repository expose IQueryable?

The repository can - and should - create complex combination objects containing multiple associated entities. In domain-driven design, these are called aggregates - collections of associated objects organized into some cohesive structure. Your code doesn't have to call GetCustomer(), GetOrdersForCustomer(), GetInvoicesForCustomer() separately - you just call myCustomerRepository.Load(customerId), and you get back a deep customer object with those properties already instantiated. I should also add that if you're returning individual objects based on specific database tables, then that's a perfectly valid approach, but it's not really a repository per sé - it's just a data-access layer.

On one hand, there is a compelling argument that Linq-to-SQL objects, with their 'smart' properties and their deferred execution (i.e. not loading Customer.Orders until you actually use it) are a completely valid implementation of the repository pattern, because you're not actually running database code, you're running LINQ statements (which are then translated into DB code by the underlying LINQ provider)

On the other hand, as Matt Briggs' post points out, L2S is fairly tightly coupled to your database structure (one class per table) and has limitations (no many-many mappings, for example) - and you may be better off using L2S for data access within your repository, but then map the L2S objects onto your own domain model objects and return those.

这篇关于MVC：库和服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！