und*_*dog 2 java architecture spring design-patterns hibernate
我的应用程序中有3个Service类,每个类都是针对具有相应DAO接口及其实现类的特定功能而编写的.所有服务都有不同的包.
说我有
AService.java & ADAO.java
ADAO接口注入AService.java类.同样我也有
BService.java & BDAO.java
CService.java & CDAO.java
Run Code Online (Sandbox Code Playgroud)
现在我想在AService.java中引用BDAO和CDAO实现类的一些方法
最好的方法是什么?
我在AService.java中注入了BDAO和CDAO.那会是一个好习惯吗?在这种情况下,服务紧密耦合.
我在各自的DAO中编写冗余代码.
我创建了一个通用的DAO并尝试从所有单独的DAO中提取所有常用方法并将其放入其中.这是一项艰巨的任务.此外,我不确定将来在哪种特定服务中需要哪种DAO方法.
小智 5
在这种情况下,我会选择第一个选项.服务可以比DAO具有更高的抽象级别.
我肯定不会采用第二种方法,如果公共代码是一些实用程序代码,第三种选择可能是有效的,如果公共代码来自不同的实体/逻辑域,我不会这样做.
如果您在 DAO 层中共享行为,则应在 DAO 层内通过继承或组合(关联)来实现。
您可以通过域切片您的应用程序,如“A”,“B”,“C”,所以AService
应该不会被通过BService
访问任何类型B的逻辑在B域实现的。
见@oliver-gierke谈话“哎呀!我的架构去哪儿了?” . 由于这种简单的绕过,他建议像这样组织包
public class com.product.a.AService
/*package*/ class com.product.a.ADao
public class com.product.b.BService
/*package*/ class com.product.b.BDao
public class com.product.c.CService
/*package*/ class com.product.c.CDao
Run Code Online (Sandbox Code Playgroud)
有了这个,你就强制没有其他“域”在使用你域的道。否则,您可能会违反您的架构规则。
共享不同域的 DAO 的问题在于,您可能会绕过在其他域服务层中实现的业务逻辑。例如,B
电子邮件上的每个“删除”操作都应该发送给客户。如果直接AService
使用BRepository
,它授予访问权限以删除 B 实例并绕过发送电子邮件的逻辑。
归档时间: |
|
查看次数: |
383 次 |
最近记录: |