我应该始终使用服务，还是可以直接使用存储库？

Question

当我尝试遵循 DDD 时，我是否应该始终访问这些服务？

或者我可以直接使用存储库来获取域对象吗？

Answer 1

就我个人而言，我不喜欢在控制器或一般表示层中看到存储库。但我已经看过很多次了，在 DDD 的背景下它没有任何问题。

我认为答案是这取决于你的项目有多大。服务层更常见于更复杂的项目中。而更简单的 MVC 网站则直接使用存储库。

Answer 2

或者我可以直接使用存储库来获取域对象吗？

你绝对可以。这正是存储库的目标。我想知道您会使用哪种服务来实现此目的（除了在 SOA 或基于 Web 服务的架构的特定上下文中）。

Answer 3

在完成我的第一个使用 DDD 原则构建的项目后：D，我发现拥有可供应用程序层使用的域服务和存储库非常有用。

要点：应用程序层可能是您的 WCF 服务或 Web 服务中的代码（如果您使用该架构）。这一切都取决于您的实施。如果它适合您的实现，您的应用程序层可能与表示层相同，从而使应用程序层代码位于您的控制器或 Web 表单代码后面。

存储库的功能类似于内存中的集合。对于应用程序层来说，代码应该看起来就像您只是在使用任何旧的集合。

领域服务的功能更像是信息的处理器或访问器，这些信息永远不会更新，可能会被处理，但不会直接更新。对于应用程序层来说，代码应该看起来就像您只是在使用任何旧的 Web 服务。

话虽这么说，我将用一些示例进行更多解释：

存储库

我的存储库实际上继承自一个通用集合，该集合使用我创建的实现对象进行类型化，该实现对象将数据库密钥和业务模型封装在一起。使用这种方法，我可以在接口中定义一个索引器，例如

BusinessObject this[int index];

，我可以有一个 getter，它将根据底层集合的索引返回业务对象，还有一个 setter，它将从底层集合中查找数据键并保存对象到数据库。这使得应用程序代码变得非常简单，例如

IBusinessObjectRepository repository = new SqlBusinessObjectRepository(sqlString);
BusinessObject obj = repository[0]; //Get first object in the list.
//Make some changes to the business object by setting properties or calling methods to process business logic.
repository[0] = obj; //Save the object back to the database.

服务，

我使用服务来检索实体和值对象的列表，我不会单独编辑这些列表，在我的例子中，它们仅用作可用选择或调用聚合根上的方法时的值。通常，我将这些信息缓存在网络服务器上。这不是域服务的唯一用途，只是我的示例。应用层代码仍然比较简单。

IBusinessService service = new ImplBusinessService(implementationArgs);
List<BusinessObject> objsToCache = service.GetBusinessObjects();
//cache the objects on the web server.

总之，根据我对 DDD 原则的理解，应用程序层应该能够从服务或存储库访问业务对象。它们之间的选择取决于最适合领域模型的内容。