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