项目分层:
实体层:bean、pojo等
用途:和数据库的实体保持一致。
数据访问层:dao层,以及到曾的实现类
DAO层主要是做数据持久层的工作,负责与数据库进行联络的一些任务都封装在此,DAO层的设计首先是设计DAO的接口,然后在Spring的配置文件中定义此接口的实现类,然后就可在模块中调用此接口来进行数据业务的处理,而不用关心此接口的具体实现类是哪个类,显得结构非常清晰,DAO层的数据源配置,以及有关数据库连接的参数都在Spring的配置文件中进行配置。
业务层:service层,以及service的实现类
具体用途:Service层主要负责业务模块的逻辑应用设计。同样是首先设计接口,再设计其实现的类,接着再Spring的配置文件中配置其实现的关联。这样我们就可以在应用中调用Service接口来进行业务处理。Service层的业务实现,具体要调用到已定义的DAO层的接口,封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性,程序显得非常简洁。
【
- DAO层,Service层这两个层次都可以单独开发,互相的耦合度很低,完全可以独立进行,这样的一种模式在开发大项目的过程中尤其有优势,Controller,View层因为耦合度比较高,因而要结合在一起开发,但是也可以看作一个整体独立于前两个层进行开发。这样,在层与层之前我们只需要知道接口的定义,调用接口即可完成所需要的逻辑单元应用,一切显得非常清晰简单。
- DAO设计的总体规划需要和设计的表,和实现类之间一一对应。
- DAO层所定义的接口里的方法都大同小异,这是由我们在DAO层对数据库访问的操作来决定的,对数据库的操作,我们基本要用到的就是新增,更新,删除,查询等方法。因而DAO层里面基本上都应该要涵盖这些方法对应的操作。除此之外,可以定义一些自定义的特殊的对数据库访问的方法。
- Service逻辑层设计
- Service层是建立在DAO层之上的,建立了DAO层后才可以建立Service层,而Service层又是在Controller层之下的,因而Service层应该既调用DAO层的接口,又要提供接口给Controller层的类来进行调用,它刚好处于一个中间层的位置。每个模型都有一个Service接口,每个接口分别封装各自的业务处理方法。
- 在DAO层定义的一些方法,在Service层并没有使用,那为什么还要在DAO层进行定义呢?这是由我们定义的需求逻辑所决定的。DAO层的操作 经过抽象后基本上都是通用的,因而我们在定义DAO层的时候可以将相关的方法定义完毕,这样的好处是在对Service进行扩展的时候不需要再对DAO层进行修改,提高了程序的可扩展性。
控制层:controller层
负责页面跳转
无工作流的简单请求处理器
用于处理完成XHTML表单生命周期的表单控制器
向导控制器,提供多页面工作流
WebWork风格的一次性控制器
灵活的,多个动作的控制器
Controller故意设计成单例,像Servlet一样。作为单例,他们可以处理并发的请求,因此不需要在每个请求中维持状态。
spring配置文件applicationContext.xml就是spring容器,
<!--注入 dao -->
<bean id="userDaoImpl" class="com.hengdait.spring.dao.impl.UserDaoImpl" />
class里面的类被ioc容器拿去创建对象,id是bean的识别节点
<!-- 注入service -->
<bean id="userServiceImpl" class="com.hengdait.spring.service.impl.UserServiceImpl">
<property name="userDao" ref="userDaoImpl"></property>在service层里面注入dao层,因为在service层要用dao层的对象调用dao层的方法,创建的对象传给userDao(userDao为在serviceImpl里面声明的对象)
</bean>