以前在做JAVA开发的时候,通常我们的设计是Service,DAO,Domain。
但最近接触到了ror,对其中的一些设计很是喜欢。比如。
user.save()当然是还有其他数据库操作的。
但是反观Java中的设计就十分猥琐。按三层结构下,我们需要定义一个DAO接口及其实现,Service接口及其实现。
更猥琐的是,Service接口中的定义与DAO定义其中有相同的。
比如:save,update,delete,find。如此。
当然我不知道现在各位是如何设计的,因为差不多本人已有1年未接触JAVA了,但我刚才看了几个帖貌似还是这个状况。
我大概琢磨了一下利用JAVA来实现类似ROR所提供的Model CRUD
先列出该方式存在的问题和需要解决:
1.DAO没有接口设计。只是有个定义而已。
2.如果更换数据库或是数据库操作实现可能无法很优雅的解决。
3.需要创建一个类似Hibernate中Criteria的查询对象,避免绑定数据库操作框架,如Hibernate换到iBatis。
4.或是还有更多无法预料的问题。
好了。列一下代码:
1.先定义一个通用DAO接口,我也不知道为什么要定义这个东西,一个小小的习惯而已。当然。这里完全可以把方法定义加进去。以后再换个其他数据库操作实现只需要加一个类implements这个接口即可,而不需要去查找现在的实现里有哪些方法。
public interface GenericDAO<t, id="" extends="" serializable=""> {
//暂时现在的解决方式中没有任何方法定义
}
2.创建一个通用DAO接口实现,你可以直接往下拉看第三步了。这里代码很长,就是一些通用的数据库操作方法,需要自行实现,具体用JDBC,Hibernate那就自己写了。
public class GenericDefaultDAO<t, id="" extends="" serializable="">
implements GenericDAO<t,id> {
public static<t> List<t> findAll(MyCriteria...myCriteria) {
// TODO Auto-generated method stub
return null;
}public static<t,id> T find(ID id) { // TODO Auto-generated method stub return null; } public void save() { // TODO Auto-generated method stub } public static<t> void save(T object) { // TODO Auto-generated method stub } public void delete() { // TODO Auto-generated method stub } public static<id> void delete(ID id) { // TODO Auto-generated method stub } public void update() { // TODO Auto-generated method stub } public static<t> void update(T object) { // TODO Auto-generated method stub }
}
3.创建自定义DAO类(注意是类不是接口),其中实现自定义类需要的常用查询方法。但是自定义的方法必须使用父类提供的方法实现,这样可保证父类的数据库操作方式改变下层代码无需更改。
public class UserDAO extends GenericDefaultDAO<user, string=""> {
public static List findBySex(String sex){
MyCriteria criteria = new MyCriteria();
//设置criteria参数
this.find(criteria);
}
}
4.创建Model
public class User extends UserDAO{
private String loginName;
private String name;
private String password;
//......很多属性
}
5.使用,很多情况下我们都是在find
User user = User.find("1");
user.setName("风花雪月饼");
user.save();
主要问题就是MyCriteria如何设计的问题。暂时我还没发现其他问题。
至少。我不要再向Service中去注入DAO了。。。多爽的一件事情啊。。。
大概就这些了。还想写点什么,可是在太困了。想不起来了。
问题补充:
主要考虑是扩展性和API的简洁性。
当然这个考虑可能和语言有关。
ROR中通过继承ActiveRecord来实现save等CRUD.
在本次JAVA里的实现实际也是如此。
关于委托模式,首先创建一个MODEL的时候肯定代码要比User user = new User();多吧?
这里可以看到GenericDefaultDAO的定义名,原来是叫GenericHibernateDAO。后来一想,如果我改成iBatis那我需要修改多个Model。
如果叫default,那么届时我增加一个iBatis实现类,也叫这个,然后把现有的改个名字,就完成了数据库操作层的扩展。
我觉得灵活和扩展性应该是可以按一定范围来确定的。而不是把设计模式都完全的应用进去。