一个电商项目的Web服务化改造3：改进方案の规范和约定、单表、单一职责

     最近一直在做一个电商项目，需要把原有单系统架构的项目，改造成基于服务的架构，SOA。

     有点挑战，做完了，会有很大进步。

  上一篇，我们描述了原有项目中的问题。
  或者说是，本篇的基本背景。

  本篇开始，给出我们的改进方案和技术架构。
  不过，根据自己的理解，我先列出了“规范和约定”。

  因为，我认为“规范和约定”是具体方案和解决办法的基石，也是很多互联网项目的基本准则吧。

  2.改进方案和技术架构
 

   2.1规范和约定
 

   2.1.1代码规范

      用准确的英文单词，给类、函数名、变量名

      get,add,update

      更多细节，参考“Java代码规范-小雷.pdf”和“JAVA编码规范.pdf”
 

   2.1.2约定优于配置，约定优于注释

         数据库表名和字段名、Java类、函数、变量名

 
        约定优于配置
        约定优于配置（convention over configuration），也称作按约定编程，是一种软件设计范式，

旨在减少软件开发人员需做决定的数量，获得简单的好处，而又不失灵活性。

本质是说，开发人员仅需规定应用中不符约定的部分。

例如，如果模型中有个名为Brand的类，那么数据库中对应的表就会默认命名为brand,Controller的名字默认命名为BrandController。

只有在偏离这一约定时，例如将该表命名为"product_brand"，才需写有关这个名字的配置。  

     约定优于注释
    这个是我自己的见解。
     用标准，统一的英文单词，给变量和函数等命名。
    比如数据库表brand表有个字段name。
    BrandDao有个add和update方法。

   brand:就是品牌的意思
   name：就是品牌的名称
   add：就是增加一个品牌，BrandDao中，千万别用addBrand这种啰嗦的命名方式，类名中已经包含了Brand，里面的dao就是和brand相关的。
   update：就是更新一个品牌

  不用去写注释，也不用去和相关人士，过多解释这个字段的意思，这个函数的作用。
  望文生义，通过名字就可以知道准确的意思，就不用多费口舌了。

  对于那些复杂的代码，比如订单支付过程中，有一些不好理解的业务逻辑代码，再写简洁的注释。
 

   2.1.3单表 

       a.服务分离
          web服务比较多，到处都是， 一个服务和对应的数据库是逻辑上在一起的。
          感觉有点说不通呢？多表凭啥不能做到“服务分离” 。
          更准确的理由，应该是下面提到的“分库分表”，然后才是“服务分离”这个 。
 

       b.不方便缓存
          单表的结果集，方便缓存，而多表则不合适。
          比如user表有roleId字段，查询用户的时候，查1个用户，再根据roleId查角色信息。
         但是，关联的角色名称可能变化了，或者user用户信息变了，而角色不变。
          那么，可以单独缓存user或者role。
         而多表的情况下，还是都查询了数据库。 
 

       c.联合查询，效率低
         当数据量大的时候，笛卡尔积很大，10000*10000，占用的内存很大。
         假设内存足够的话，笛卡尔积的过程，也很需要时间。

        而单表查询，没有笛卡尔积的过程，先批量查A，比如10条，再批量去B查，1次10条，代码组装，数据就够了。

        这里面存在一个问题，当A-B表关联查询，但是查询条件是B表字段的时候，这个是否必须“关联查询”。
        比如，根据用户角色名称，查询用户，获得第1页10条数据。

        如果还是单表的情况，就需要做“冗余”。

       因此，我们说“单表”存在2个含义。
       一、只有自己一个表的数据，二、物理上是一个表，但逻辑上有2个表的数据。
 

       d. 并发
          每个表数据量、查询查询、修改次数等都不一样。
          单个表，如果需要锁住一行，也更加精准。
    
          这个地方，还不是特别确定。 
         单表锁一行：select * from brand where id =1 for update
         多表锁一行：select * from user left join  role on user.roleId = role.id where roleId = 1 for updte ？
 
         准确的说，以上是“并发修改” 中的1个例子，还有“并发查询”等很多种并发场景吧。
 

       e. 如何分表、分库
           数据量大的时候，需要分表分库。
          分表分库之后，联合查询就很废材了。
 

        f.根据业务场景和特性，分别做优化

           实际情况，user、role、brand等查询量、修改量等都是不同的。
           这一点，和把整个项目拆分成商品product、用户user等思想是类似的。
           拆分成更小粒度的，方便做优化。

     疑问： 既然MySQL多表这么废材，为什么当初设计MySQL等数据库的时候，都有关联查询等一大堆功能特性呢？
    难道是因为互联网崛起，超出了当初设计者的想象力？ 

   2.1.4单一职责

         一个类、一个函数，只做一件事，只完成一个功能。
         一个接口集，对外提供的服务，也是紧密相关的。 

   个人观察：多问几个为什么，可以发现更多的问题，学到更多更深入的“知识点” 。
                    用单表是好，为啥不能用“多表联合查询” ，通过对这个问题的思考和交流，理解更近了一步。

   约定优于注释，算是我的独家见解吧~