有新人学了spring,觉得通过dao接口,通过工厂方法, 然后实现登陆的功能,其实把简单的问题复杂化了,不如直接在javabean写一个方法写一个sql来的简单有效.
---------------------这一点我是认同的,从这段程序来看,后者的确来的有效.
但现在很多人不这么用了.他们当然是有理由的,我也有些理解,就在这里说说......这里我是描述自己的意思,希望大家容易理解.不代表权威很正确.
这里我们看登陆的功能,核心部分就是根据客户提交的用户信息(一般就是用户名和密码)去数据库检查是否有对应合法的用户信息.有就ok,没有自然就不ok.
这里肯定是有一个对象"用户"(比如是User.java)和一个方法"检查用户信息"(比如checkUserInfo()).
使用DAO简单的说就是把对象和方法分开成两个类写,
直接用javabean简单的说就是都写到user.java类中.
这里我们理解下DAO.下面是我从baidu上找的解释
DAO是Data Access Object数据访问接口，数据访问：故名思义就是与数据库打交道。夹在业务逻辑与数据库资源中间。
在核心J2EE模式中是这样介绍DAO模式的：为了建立一个健壮的J2EE应用，应该将所有对数据源的访问操作抽象封装在一个公共API中。用程序设计的语言来说，就是建立一个接口，接口中定义了此应用程序中将会用到的所有事务方法。在这个应用程序中，当需要和数据源进行交互的时候则使用这个接口，并且编写一个单独的类来实现这个接口在逻辑上对应这个特定的数据存储。
在面向对象编程的含义上理解,写在一起是比较好理解的,因为检查用户信息是user提供的一个接口方法嘛.
这就是充血模式,就是对象的一些方法都写到一起.一个类中
在追求送藕合编程的含义上,分开写是比较好理解的,因为对象和业务方法进行了分离嘛.这就是失血模式,就是对象的一些方法都分开写到一个类中,一般名字就是对象名+DAO.java比如UserDAO.java
很久以来业界有一些争议,我认为是没有对和错的,只是在不同的环境不同的系统,他们有各自的好处和坏处,核心还是一点,我们的目的不是技术,技术是为我们实现服务的.
这里在说下Spring,我对spring的理解不算很透彻,spring在hibnernate的封装那里,操作比较规范的,可以做一个统一的DAO接口,然后每个对象可以做一个DAO类实现这个接口.然后在业务中获取(这里有spring的ioc,就是一种工厂方法,这里就不说了)调用.从这里来看,一个简单的步骤,的确复杂了不少,所以我开始说---------------------这一点我是认同的,从这段程序来看,后者的确来的有效.
这里就要说大道理了
一个系统,并不仅仅就是几段代码.对应一个很小的系统,完全没必要考虑什么dao什么框架之类的东西,spring更不用考虑可,让每一行代码运行的时间最短最有效,就是最好的.
但是对于一个大的系统,一个团队开发的系统,不考虑dao不考虑框架(这里的框架可能是自己开发的框架,框架是一种流程结构,大家理解不要太狭隘的理解就是struts之类,我见过一个朋友的系统,算是很大了,联通公司使用的,他们就使用了jsp,javabean,servlet而已,感觉很不错,他们应该就是自己写了框架)是不行的,这里就涉及到系统设计代码管理之类的东西,分工合作如果不规范统一管理,那么这个系统就算做好了,维护更新扩充都是很麻烦,在程序员变更的时候也是非常浪费公司资源的,对于大的系统,性能不是唯一重要的东西,可维护性可扩充性,是必须要考虑的.所以,软件工程方法论等等也是在这种背景下不断进步的.
复杂的东西没有简单的东西有效,就象hibernate在性能上比不上直接用jdbc样.struts,spring等等或许也比不上直接用jsp,serlvet.但是我们做一个项目一个系统,我们追求的更多,不仅仅是几行代码效率而已.(
说完了,
总结一句废话,合理的选择适合的技术,快速有效的开发我们的系统.技术不是我们的目的.