刚刚開始接触三层的时候，我仅仅做了两个登录小窗口的样例。画了简单的包图，能够说，为后面机房重构留下了大量的工作（由于三层理解没有深度，也没有理解出自己的东西）。只是。欠下的总要还的。
在做机房重构的时候，问题出现了。
假设仅仅用三层+实体。我能做出来。可是，要求重构不能仅仅用三层+实体，那么，就要好好分析一下了。
首先说说三层+实体：就是表现层（U层）直接调用业务逻辑层（B层）的逻辑。业务逻辑层在直接訪问数据层（D层），在把数据返回到B层后返回到U层。首先，仅仅用三层＋实体做程序时，灵活性不够高。假设想换数据库的话。须要大量修改B层的代码。
其次，代码利用率不高，像訪问数据库的一些代码，多次反复。
既然不好，就有必要寻找新的方法。B层直接訪问D层不好。怎么办呢？用接口。这样，假设更换数据库。仅仅要把D层进行改动或者在连接新的D层，而不用更改B层的代码了。实现“高内聚。低耦合”。
U层直接訪问B层，U层须要知道B层的就太多了。耦合性太高。我们的系统简单。一个上机窗口里面就两个主要功能，可是一个窗口上面内容多的话，那U层和B层的相应关系不是非常乱了么？这时外观就出动了。
假设U层通过外观訪问B层的话。能够避免这一问题。
那么，又为什么要使用SQLHelper呢？事实上，SQLHelper是一个工具。主要是为了规范代码和降低代码编写，假设想了解很多其它，能够參看还有一篇博客：SQLHelper
以下是我画的由三层+实体到三层+实体+外观+接口+工厂+SQLHelper的包图，欢迎指正
小结：首先，不管在学什么知识的时候，即使非常easy，也要小结几句，否则下次想用时，无从下手。三层就是个活样例。其次，多请教，多交流。对于不会的东西。勤于动手。等待是解决不了问题的。
再次，对于三层这块，仅仅要通了，感觉就好多了。刚刚開始做包图的时候，真的是无从下手。即使给你现成的图，也会有看不懂以及为什么会是这个样子的疑问（我相信不止我自己有这样的感觉）。
我建议，假设出现这样的情况，先放一放图，试着通过代码，了解一下这个过程，尽管可能有点难度。可是总比停下来或者揪住一点不放要好的多。
PS：欢迎指正，不胜感激！