DDD 中的服务和存储库 (C#)
Services 和 Repositories 在 DDD 中如何相互关联？我的意思是，过去 2 天我一直在阅读 DDD，无论我走到哪里，总是有一个 Service 层，并且总是有一个 Repository 层。它们如何区分或互补？
据我所知，Repository 不是负责委托应用程序和数据之间交互的层吗？
那么，如果 Service 层必须实现 Repository 来与数据交互，那么它还需要什么，即使 Repository 可能已经实现了需要采取哪些方法？
我希望对这个主题有一些启发。
PS 不知道这是否有帮助，但我正在使用 ASP.NET MVC 2 应用程序，在其中尝试实现存储库模式。我刚刚完成依赖注入模式的实现（有史以来第一次）...
更新
好的，有了这么多答案，我想我明白了其中的区别。因此，回顾一下（如果我错了，请纠正我）：
Repository 层仅与数据库或 ORM 中的单个对象交互，
IEmployeeRepository- >Employee。Service层封装了从Repositories（一个或多个）返回的对象上更复杂的功能。
那么，我有一个小问题。创建抽象对象发送到我的视图是否被认为是不好的做法？例如 AEmployee （A 代表 abstract，因为对我来说 I 意味着 interface）其中包含来自 Employee 和 X 或 X 的属性？
实际上，还有一个子问题。如果Service层可以被认为是针对应用程序“调整”的，那么它是否需要使用接口来实现？
How do Services and Repositories relate to each other in DDD? I mean, I've been reading up on DDD for the past 2 days and everywhere I go, there's always a Service layer and there's always a Repository layer. How do these differentiate or compliment each other?
From what I've read, isn't the Repository the layer responsible for delegating interactions between the application and the data?
So, what's the need for the Service layer if it has to implement the Repository to interact with the data anyway even though the Repository probably already implements the methods needed to do so?
I'd appreciate some enlightenment on the subject.
P.S. Don't know if this will help any, but I'm working with an ASP.NET MVC 2 application in which I'm trying to implement the Repository pattern. I just finished implementing the Dependency Injection pattern (for the first time ever)...
UPDATE
Okay, with so many answers, I think I understand what the difference is. So, to review (correct me if I'm wrong):
A
Repositorylayer interacts only with a single object out of the database or the ORM,IEmployeeRepository->Employee.A
Servicelayer encapsulates more complex functionality on objects returned fromRepositories, either one or multiple.
So, then I have a sub question. Is it considered bad practice to create abstract objects to be sent to my views? For example an AEmployee (A for abstract because to me I means interface) which contains properties from Employee and X or X?
Actually, one more subquestion. If a Service layer can be considered "tuned" for an application does it need to be implemented with an interface?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
服务将使用存储库来检索实体，然后调用其（实体）上的方法来执行命令/任务。
The Service will use a Repository to retrieve an Entity and then call methods on it (the Entity) to perform the Command/task.
确实，存储库与数据一起工作（即 SQL、Web 服务等），但这只是唯一的工作。 CRUD 操作，仅此而已。没有基于存储过程的业务逻辑的位置。
服务（或业务逻辑层）提供功能。 如何满足业务请求（即计算工资），什么你必须做什么。
哦，这是一本非常好的 DDD 书：
http://www.infoq.com/minibooks/domain-driven-design-quickly
True, a repository works with data (ie. SQL, Webservice etc.) but that's the only job. CRUD operations, nothing more. There is no place for stored procedure based busines logic.
The service (or business logic layer) provides the functionality. How to fullfill a business request (ie. calculate salary), what you have to do.
Oh, and this is a really nice DDD book:
http://www.infoq.com/minibooks/domain-driven-design-quickly
作为一个具体示例，购物车应用程序可能具有以下服务：
ShoppingCartService - 管理购物车中的商品，并支持添加/删除/更新等。
OrderService - 获取购物车，将其转换为订单并处理支付流程等。
这些服务中的每一个都需要与 CRUD 操作的“数据源”进行对话。这就是存储库模式派上用场的地方，因为它抽象了数据源（无论是数据库、Web 服务甚至内存缓存）的数据加载和保存。
当您想要创建应用程序的快速原型而无需处理数据库设置、架构、存储过程、权限等时，您可以在几分钟内创建一个缓存或假存储库。
对于上面的示例，您的原型可能从以下内容开始：
一旦您的原型准备好发展到下一个级别，您就可以针对真实数据库实现这些：
As a concrete example a Shopping Cart application might have the following services:
ShoppingCartService - manages a cart of items with add/remove/update support etc.
OrderService - take a cart, converts it to an order and handles the payment process etc.
each of these services needs to talk a "data source" for CRUD operations. This is where the Repository pattern comes in handy as it abstracts the loading and saving of data to and from the data source be it a database, web service or even in-memory cache.
When you want to create a quick prototype of your application without having to deal with database setup, schema, stored procedures, permissions, etc. you can create a cache or fake repository in a matter of minutes.
For the example above your prototype might start off with the following:
once your prototype is ready to evolve to the next level you can implement these against a real database:
据我所知，存储库是数据之前的最后一个类。服务类可以对从存储库检索的数据进行操作。存储库实际上只是为了将数据提供给其他人来完成工作。服务层可以提供所有数据必须经过的业务逻辑等东西。它还可以提供应用程序逻辑和数据层之间的转换。但话又说回来，这就是我能记得的。
From what I can remember, the repository is the final class before the data. The service class can act on data retrieved from the repository. The repository is really just meant to get data to somebody else to do the work. The service layer can provide things such as business logic that all data must pass through. It could also provide for a translation between the application logic and the data layer. But again, this is just what I can remember.
没有定义服务或存储库的黄金标准。在我的应用程序中，存储库（如您所说）是数据库的接口。服务可以完全访问存储库 - 但服务向其使用者公开功能的子集。
将存储库视为更低级别的。存储库必须公开访问底层数据库的多种方式。服务可能会将对存储库的调用与仅在代码级别（即不在数据库中）有意义的其他代码结合起来，例如访问应用程序中的其他状态，或无法轻松应用的验证/业务逻辑。一个数据库。
There's no golden standard that defines a service or a repository. In my applications a repository is (as you say) an interface into a database. A service has full access to a repository - but the service exposes a subset of functionality to its consumers.
Think of the repository as more low level. The repository has to expose many ways of accessing the underlying database. A service might combine calls to a repository with other code that only makes sense at a code level (i.e. not in the database), such as access to other state in the application, or validation/business logic that can't easily be applied in a database.