对于服务层中的大多数操作,它似乎是直接映射到CRUD操作,GetAll,GetById,创建,删除等.架构流程在这些行中：我有一个控制器调用服务层调用一个调用ORM的存储库,它与后端进行通信.
因此,例如GetAll将存在于SL和Repository中.现在,如果我们有一个变更/业务要求,GetAll应该忽略某些项目,我应该怎么做,我应该忽略存储库中的这些,还是应该进入服务层的业务逻辑？如果我们只是让服务层直接调用ORM,那么生活会不会更容易？
总结一下：我理解服务层可以抽象一些业务逻辑,但是在大多数情况下 – 它处理简单的CRUD操作,是不是更容易摆脱存储库？但是,如果SL还包含一些具有复杂业务逻辑的方法,那么它们应该通过存储库吗？从良好的设计角度来看,我是否应该支持一致性并始终通过存储库或只是保持简单,只使用存储库,而不是简单的一对一映射到CRUD操作.
PS：我发现似乎有类似的问题,但没有找到任何令人满意的答案
解决方法
I noticed that we end up with situations where there is duplication
between the Service Layer and the repositories that feels like a code
smell.
它不是代码味道,因为它们做不同的事情.
您应该记住,域或应用程序服务驻留在与存储库实现不同的层中.层是有原因的 – 不同层中的对象不具有相同的职责,也不与相同的邻居交谈.存储库实现与对象持久性的方式紧密耦合.他们可能会生成sql语句并与关系数据库交谈,他们可能会与您的ORM交谈……重要的是他们知道对象的持久化方式,而Application Services则不然.
如果您的服务层要直接调用ORM,它实际上会做两件大事,违反单一责任原则.将ORM更改为另一个ORM或使用不同的持久性方法也会更加困难.
So for example GetAll would exist in both SL and Repository. Now,if
we have a change/business requirement that GetAll should ignore
certain items,how am I supposed to do it,should I ignore these in
the repository,or that’s business logic that should go in the Service
Layer?
如果GetAll()忽略某些项目,我强烈建议在服务和存储库中重命名它以反映它,例如：GetAllAllowedToUser(),GetAllBut …().因此,方法的合同将是明确的,你将避免误解它应该返回什么.另外,您将能够保留原始的正版GetAll()方法,这种方法仍然有用.