DDD & DDDLib在恒拓开源的发展历程与推广经验

Resource newResource(String name,String identifier,String level,String menuIcon){　　Resource resource = null;　　List<Resource> resources = Resource.getRepository().find("select r from Resource r where r.name = ? " + "and r.identifier = ?", new Object[]{name,identifier}, Resource.class);　　...}

　　这个很是容易明白：那里要查询，那里写SQL，这种模式是公司最初的使用方式，优弱点也很是显着。优点是直观，弱点则是，DDDLib提倡隔离特定手艺，那这些语句写在写到代码中，意味着领域层中依赖了特定的手艺语句，违反了DDDLib的目的。

　　2、以@NamedQuery注解写在类上

@Entity@NamedQuery(name="findAllEmployeesByFirstName",queryString="SELECT OBJECT(emp) FROM Employee emp WHERE emp.firstName = 'John'")public class Employee implements Serializable {　　...} 

　　在Koala产物泛起以前，DDDLib支持Hibernate以及JPA，这两种模式都支持@NamedQuery这种注解。曾经有人提议过这种方式，但并没有解决上面的问题，反而带来难以阅读的问题。

　　3、以命名查询+xml实现

/*** 判断一个资源是否有子资源*/public static boolean hasChildByParent(Long parentId) {　　return !Resource.findByNamedQuery("hasChildByParent", new Object[] { parentId }, Resource.class).isEmpty();} 

　　在对应的 XML 设置中界说：

<named-query name="hasChildByParent"><query>select distinct m.id from ResourceLineAssignment m where m.parent.id=?</query></named-query>  

　　Koala团队后期定制了我们的方式，使用命名查询+xml设置方式来实现，而且基于这种方式，提供了MyBatis协议的支持实现，获得了一定的认可。

　　使用这种方式，领域层的代码中不会泛起特定的手艺语句，解决了上述问题，差别的手艺实现下差别的xml设置这种模式是可以接受的。

　　但这种模式也仍有一些问题，包罗：

　　a) 动态条件查询不支持。一些查询的条件是动态的，这种模式下的HQL/JPQL是不支持的，但由于通常动态条件查询不属于营业焦点，而是应用需求是在应用层，因此暂时仍然可以接受。

　　b) 扩展其它存储介质的问题。Hibernate/JPA/MyBatis是常用的持久层框架，可是现在越来越多的泛起诸如NoSQL、云存储等非关系型存储，使用这种模式来匹配这些存储，当前没有现成的解决方案

　　4、不使用语句，而使用QueryCriterion

　　DDDLib中提供了QueryCriterion这种查询机制，以期望做到隔离特定持久层框架的影响。很惋惜，早期在恒拓推广使用 DDDLib 时，没有提及这种实现，因此恒拓的DDD一直未使用此方案。

 3/5   首页 上一页 1 2 3 4 5 下一页 尾页