三层——WHY

    说到分层，无非是建类库、做接口、引用等等来提供交互，想必语言都差不多。然后设计模式就可以穿插作用在里面了。

    分层是种思想，确实界面层和数据层两层也能处理业务，那为什么我们要添加业务层呢？当然是为了提高效率！举个栗子，说说为啥分出个业务层就高效了呢？我们为什么要学习分层这种思想呢？
 
    附近开了一家台湾私房小吃。店小，可以直接看到厨师忙活，厨师可以直接把做好的餐点放到柜台上；取餐也有一点自助式，顾客可以自己到柜台取餐也可以由送餐员送到桌子上。前天跑去吃，点餐的时候恰巧听到老板对着一伙计（看起来是厨师）训话，意思是不能你看到客人点什么恰巧做的是这一样就递给他，这叫打乱账。这么样做让早来的客人等的久，是不是不公平？让前台接单员的怎么理账？等等
 
    看到这里，那么问题来了，如果厨师直接面向顾客会发生什么事呢？

        1、对于客人，早来的客人久等，客户体验不好；
        2、对于点单员，账单错乱，无法告诉送餐员不知道哪个送餐哪个不送餐；
        3、对于送餐员，送餐难度加大；
        4、对于整个餐厅，不能上传下达，往往尾大不掉，难以实现高效；
    ……
 
    那么我们用三层的思想分析一下这件事
    点单员属于界面层，直接受理顾客的需求；送餐员属于业务层，面对客户需求做出相应反应；厨师属于数据层，实现顾客的需求，但不应该同客户直接接触。
    该店厨师的行为，直接履行了业务层的义务，看起来减少了一个步骤似乎结果却并不高效（否则boss就不会训他了）。
 
    如何才能高效起来呢？我们再延伸开来
    如果订单类型是下图这三种呢？

 

    订单1，（小商家）客人少菜品少，分层可，不分层也能运营；
    订单2，（中型菜馆）专门单出一个业务层就可以更好的处理事务了；
    订单3，（美食广场）要求越来越简略，可是表示的内容更复杂了，不得不分层。
    可以推理如果业务越来越多元，势必业务层中也是需要分层的。
 
    所有的程序都需要分层吗？NO！分层是要考虑量级的，运用奥卡姆剃刀原则【如非必要，勿增实体】。因此处理大型业务分层的思想也就变得十分有必要，这也是为啥学习分层这种技术。