关于MVC和分层体系的一点认识

MVC

• 目录结构： MVC模式的目录结构就是MODULE, CONTROLLER, VIEW。MODULE用户存放业务逻辑；CONTROOLER连接业务逻辑和模板，其实就是调用MODULE获取到数据丢给VIEW展示出来； VIEW用于存放模板。
• 为何过时：主要原因在于在MODULE里面混杂了业务逻辑和数据存储逻辑
  1. 难维护。例如你需要对用户信息做缓存时，就需要在业务逻辑代码上动刀，这样就涉及到业务代码的改动。
  2. 难拆分。在业务逻辑中使用数据查询经常使用连接查询，比如用户表和文章表需要拆分到两台独立的数据库服务器上，或者某个表水平拆分，都会导致大量的拆SQL工作。即使连接查询会减少数据库的请求，有可能提高系统性能，但是不推荐使用连接查询。导致难维护和难拆分是主要原因，从另外一个方面考虑，到你的系统访问量、数据量很小，SQL拆成独立SQL，对系统的性能影响并不大。当你的系统大到一定程度，大到拆成独立SQL会导致明显的性能问题时，应该考虑分布式了，而不是合并一些SQL，提高性能，即使提高了，随着数据、访问量的增大，你的系统很快有进入性能瓶颈。
     3.难扩展。由于在MODULE中是直接读取SQL，没有数据存储层的概念，你很可能在用户的业务逻辑里面直接通过SQL读取订单信息，当订单或者用户业务逻辑要独立出来时，又得去修改这部分代码，这样大大增加了开发成本和风险。

分层体系结构

• 什么是分层体系结构：我个人理解就是拆分MODULE，把数据存储和业务逻辑独立出来。系统又可拆分为独立业务，比如订单，用户，文章，统计等。每个独立业务都有自己对应的业务数据，业务逻辑内部获取自己的对应业务数据，只能通过数据存储层来进行。获取其他业务数据，只能调用其他业务

• 目录结构：
  

• Common下面是各个服务公用的文件。

• 一个服务对一个目录；例如：用户服务在目录User下，标签服务在Tag下，问答服务在Question下。

• 单个服务内部结构：

  1. XXXService.php 为服务接口，Impl目录下为文件XXXServiceImpl.php均为服务接口的实现。为何使用接口，自己GOOGLE针对接口编程，可以看个简单的例子http://www.cnblogs.com/lotusswan/archive/2008/08/22/231357.html
     2.Dao为数据存取层，里面的代码只能设计数据存取逻辑，不能设计业务逻辑。每个表对应一个TableImpl.php文件**，不使用连接查询。特殊情况下，一定要使用到连接查询，可以使用Module->getDb()方法获取到DB实例后直接执行SQL。
  2. Test目录为单元测试目录。

• 使用此种结构的好处：

  1. 便于拆分业务，比如订单有两个业务，一个是常规业务，一个是统计业务，当订单统计业务过大时，可以将统计业务拆其他地方，并且只需要实现接口文件定义的接口即可，客户端只需要更改调用统计业务的方法，即可完成拆分。
     例：
     // 拆分前
     public function indexAction()
     {
     $stat = $this->getOrderStatService()->getOrdersDistinctMap();
     }

  protected function getOrderStatService()
  {

  return \Service\OrderStat\OrderStatServiceImpl::Instance();

  }

  // 拆分后
  public function indexAction()
  {

  $stat = $this->getOrderStatService()->getOrdersDistinctMap();

  }

  protected function getOrderStatService()
  {

  return RpcClient::Instance()->getService(‘OrderStatServiceImpl‘);

  }

  1. 便于数据库垂直、水平拆分：对一单个服务，很容易将Dao层独立出来，部署当单独机器上，服务只需要更改调用对应的Dao的方法就可以完成。

• Controller 和View 还是和MVC一样，不做更改