目录
全称数据访问层,全称data access object,属于一种比较底层,比较基础的操作。具体到对于某个表、某个实体类的增删改查,即用于数据库的增删改查,表达的是对SQL语句的封装,建议对DAO只做原子操作。有多少张表就有多少个DAO层。在mybatis中,方法主要与xxx.xml内一一对应,相互映射。
dao层负责与数据库联络的一些任务封装在此,dao层首先设计dao层接口,然后在配置文件中定义此类接口的实体类,然后就可以在模块中调用此接口来进行数据处理。不需要关心此接口的具体实现类,结构清晰。dao层的数据源配置以及数据库连接参数都在配置文件中进行配置。
全称业务逻辑层,在该层进行复杂的业务逻辑处理,且只专注逻辑处理,即对于多个dao层进行封装、处理。其中需要的数据库操作通过DAO层去实现。所以我们再Service层需要事务管理。
业务逻辑,就是对数据库获取的数据进行处理,比如从数据库获取num=10,逻辑操作是+1,那么+1操作由Service处理。
Service层,负责业务模块的逻辑应用设计。同样是先设置接口,再设计实现类,接着在配置文件中配置其关联。这样我们就能在应用中调用Service接口来进行业务处理。Service层的业务类具体要调用已经定义的dao层接口。
service层=service接口(可以根据业务复杂程度来省略)+service实现类
我们通过将dao层封装成Service层,让Service层去调用dao层的接口,有利于业务逻辑的独立性和重复利用。程序显得非常简介。
DAO面向表,Service面向业务。后端开发先数据库设计出所有的表,然后每一张表设计出DAO层,然后根据其具体的业务逻辑将DAO层封装成一个Service层,对外提供一个服务。
Collertroler层俗称控制层,负责请求转发,接收页面(前端H5或者App)传过来的参数,并调用Service层中定义的方法进行业务操作,再将处理结果返回前端。
Colltroler负责具体业务模块流程的控制,在此层需要调用Service层提供的接口来控制业务流程,控制的配置同样在配置文件中,针对具体的业务流程,有不同的控制器。我们的设计过程可以将流程进行抽象归纳,设计出可以重复利用的单元流程模块,这样可以使程序结构更清晰,大大减少代码量。
Controller层调用Service层的方法,Service层调用Dao(mapper)层中的方法,其中调用的参数是使用Entity层进行传递的。总的来说这样每层做什么的分类只是为了使业务逻辑更加清晰,写代码更加方便,所以有时候也需要根据具体情况来,但是大体的都是这样处理的,因为它其实就是提供一种规则,让你把相同类型的代码放在一起,这样就形成了层次,从而达到分层解耦、复用、便于测试和维护的目的。
entity实体层(model),存放的实体类,与数据库中的属性保持一致,实现set和get方法。用于各层(DAO,Service、Colltroler)之间对象数据的封装和传递