我最近才开始尝试使用 Spring Roo。它非常出色地帮助人们相当快速地构建具有集成持久性的领域模型。由于它在方面添加了持久化功能，我开始思考以下问题:
Roo 在一个方面向实际的类/实体添加查找器(从数据库加载满足变量条件的类的实例)。在 DDD 中，恕我直言，这是存储库的责任。存储库是显示在设计中的显式类。当然，作为一个方面，存储库功能隐藏在一个实体中，几乎是不可见的。
所以问题来了:方面是显式存储库类的真正替代品吗？ Roo AOP 方法有什么缺点吗？
最佳答案
从用户的角度来看，将查找器添加到您的域类感觉更自然，但它会混淆您的层。 Grails 通过添加 static finder*() save(), ... 方法来使用相同的方法。
除了美学之外，当不用于 Web 应用程序设置时，它可能有实际缺点: 您的域类现在已绑定(bind)到您的数据库。如果您通过 RMI 或 HttpInvoker 将这些对象传输到富客户端，则客户端不能而且通常不会使用 find* 方法，因为客户端上没有可用的 session /数据库连接。
我通常更喜欢允许域类引用服务层接口(interface)以防止贫血域模型 (http://martinfowler.com/bliki/AnemicDomainModel.html)。这有其自身的一系列缺点，但至少提供了一个明确的界限。在客户端，服务接口(interface)背后的具体实现可以将所有方法调用代理到服务器(或者只使用带有 spring 远程处理或类似功能的同步代理)。
所以回答你的问题:它可能是一个替代品，但你应该意识到可能的负面后果，这会使你的域类(即你的核心业务逻辑)在系统之间的可移植性降低。
关于java - 方面是否替代存储库？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2259535/