DISCUZ! X2.5框架学习

View层：用于给用户展示以及与用户交换的部分，一般来说指的是html展示部分。dz使用了模板引擎来实现，也就是代码里面的template方法。具体可以参考function_core.php文件里面的template方法。

Controller层：一般是负责具体的业务模块流程的控制，相当于一个摆渡的作用。在dz里面就是根目录的那些文件。如index.php，home.php，forum.php等文件，他们都没有实际的业务逻辑，仅仅是用来控制流程。说白了就是通过它知道你发出的请求应该调用哪个类或者哪个方法来进行处理。

Service层：主要负责业务模块的逻辑应用的，也就是具体要进行操作的一些业务逻辑处理。在dz里面就是/source/module/里面的文件。当然，根据业务逻辑的复杂程度，不仅限于这个目录里面的方法，dz还根据实际的需要和功能抽象出class、include、language等公用或者特殊的类和方法。

DAO层：主要是做数据持久层的工作，负责与数据库进行联络的一些任务都封装在此。一般来说DAO层的类相当于一个实体对象，与数据库表一一对应的。在dz里面就是/source/class/table里面的文件，应该是与数据库表一一对应的（具体没有详细对应去看）。在调用的时候，使用C::t(‘对象名称’)来调用获得DAO对象，例如C::t(‘common_member’)，则可以获得common_member的DAO对象，而该对象对应的方法则可在table_common_member.php里面进行定义。以前的版本是没有这一层的，是直接通过DB::query等数据库操作直接查询数据的，有了DAO层，在业务逻辑操作的时候更加体验了面向对象的思想。如果对dz进行的二次开发的朋友，肯定已经发现了这个变化，在业务逻辑代码里面，所有的DB::XXX的方式都换成了C::XXX。当然，dz还是保留DB::XXX等方法的使用，不过对于二次开发的话，不建议直接使用DB::XXX而是调用C::XXX。

但是这个版本的仍有美中不足的地方。虽然实现了DAO层来实现面向对象的手段，但是并没有吸收到DAO层的精华所在。因为我发现所有的table类竟然是独立的，很多公用的方法例如fetch_by_uid，fetch_all_by_uid等等通用的增删查改，都没抽取出来放到父类里面去。所以导致很多重复的代码，而且table类也因此变得很局限，对于二次开发扩展来说，不太有利。当然，官方自己开发的话不会存在局限一说，毕竟需要什么方法自己添就是了，只是会出现很多重复代码而已。