方面是否替代存储库？

Question

我最近刚开始尝试使用Spring Roo。它可以很好地帮助构建具有集成持久性的域模型。由于它在方面添加了持久性功能，我开始考虑以下问题：

Roo在一个方面向实际的类/实体添加finders（从满足变量标准的数据库中加载类的实例）。在DDD中，这是IMHO的存储库的责任。存储库是显示在设计中的显式类。当然，作为一个方面，存储库功能隐藏在实体中并且几乎不可见。

所以这就是问题：一个方面是否是显式存储库类的真正替代品？ Roo AOP方法有任何缺点吗？

Answer 1

从用户的角度来看，向您的域类添加查找器感觉更自然，但它会混合您的图层。 Grails使用相同的方法添加静态finder *（）save（），...方法。

除了aestetics之外，在Web应用程序设置中不使用它时可能会有实际缺点： 您的域类现在绑定到您的数据库。如果您通过RMI或HttpInvoker将这些对象传输到富客户端，则客户端不能并且通常不会使用find *方法，因为客户端上没有可用的会话/数据库连接。

我通常更喜欢允许域类引用服务层接口以防止贫血域模型（http://martinfowler.com/bliki/AnemicDomainModel.html）。这有其自身的一些缺点，但至少提供了明确的界限。在客户端上，服务接口后面的具体实现可以只代理对服务器的所有方法调用（或者只使用带有spring remoting的synamic代理或类似的）。

所以回答你的问题：它可能是一个替代品，但你应该意识到可能的负面后果，使你的域类（即你的核心业务逻辑）在系统之间的可移植性降低。

Answer 2

这取决于应用程序持久层的复杂程度以及对它的控制程度。如果您的应用程序非常简单，可以通过 JPA 实现，那么这一切都可以通过Roo方面进行处理。但是，如果您要映射遗留表或需要高级数据库内容，那么您可能会发现自己处于 Spring-JDBC 是唯一的出路，在这些情况下，存储库/ dao模型可能仍然有用

我认为混合两个持久性模型的逻辑不一致（以及层责任的中断），因此我的大多数应用程序都需要这样的高级DB结构，所以我严格遵守存储库模型。

Answer 3

我认为向域对象添加存储库方法是糟糕的设计。正确的位置是域类中的静态方法。但域对象及其管理是两个应该分开的不同事物。我更喜欢域对象和存储库。

我想动机是用Java实现Rails / Grails。