我目前正在学习 SOLID 原则,尤其是 SRP。
从这个原则的角度来看,我记得前段时间曾开发过一个小型应用程序,它有一个 Spring Service 类,其中包含整个应用程序的所有服务方法。
此外,它有一个包含所有 jpa 数据访问方法的 DAO 类。
这完全违反了 SRP。不是吗?
我目前正在学习 SOLID 原则,尤其是 SRP。
从这个原则的角度来看,我记得前段时间曾开发过一个小型应用程序,它有一个 Spring Service 类,其中包含整个应用程序的所有服务方法。
此外,它有一个包含所有 jpa 数据访问方法的 DAO 类。
这完全违反了 SRP。不是吗?
好吧,是的,也不是,这里的想法是,如果一个类只有一个“变化轴”(必须喜欢马丁的行话),它就是“SRP 批准的”。用凡人的话来说,这意味着:“这个阶级改变的理由不止一种吗?”。IE 如果您的服务类实际上聚合了(比方说)将调用其他服务的逻辑并对该服务调用返回的内容执行一些业务逻辑,那么该服务类将有两个变化轴:一个用于何时/如果它调用的服务会改变,另一个是当业务逻辑改变时。在这种情况下,调用其他服务的部分应该与将业务逻辑应用于返回结果的部分分开。
然而,这些东西被称为“原则”而不是“法律”,因为它们不应该一直盲目地应用于你开发的任何东西(以免你想疯了:)),但只有在上下文需要时才适用。
例如,Martin Fawler 本人认为模型(作为 Java bean)和 DAO 对象分离是一种反模式,他称之为AnemicDomainModel。作为一个很好的替代方案,请参阅Play Frameworks 模型实现。但是我敢肯定,您以及许多其他人在用 Java 构建数据访问层时确实已经进行了这种 bean/dao 分离,并且代码本身是干净、可用和灵活的。