- 这些天一直在看三层架构和设计模式，从网上找了很多有关这方面的资料，统统拿来看了一遍，从而对三层架构有了一个理论上的了解，只是在头脑里大概有这么个印象软件分层思想，其实，软件并不是一定要分为三层，古语“三”为多的意思，可以理解为多层，你可以分二、三、四、五、六……等，很多层次结构，但是呢，其实，主要还是分了三层，多出来的一些层是为了使三层中每一层的细分，让它们之间耦合度更低才出了很多层。例如：你可以在DAL层，添加一个IDAL接口层，总之呢，分几层不重要，具体分几层要看是否很好的符合高内聚、低耦合的思想。
- 一切只停留在思想、理论的层次上，总是感觉空洞，似懂非懂，华而不实之感，学习之后也用不到实践当中，实践才是硬道理，下面我用三层实现了一个登录窗体。
- 写这个窗体的时候，我经过了反复更改、重构，因为是一个验证用户登陆的，我改动的地方主要在BLL层与DAL层之间，第一次我做只是简单的搭建了一下三层UI、BLL、DAL，DAL层实现数据访问，然后，返回一个DataSet对象给BLL层，在BLL层进行用户名和密码的逻辑验证，开始写出来感觉还不错，比不用三层感觉好一些，后来，通过对网上三层实例经典的是微软的PetShop实例以及一些三层资料进一步研究，感觉自己这样写还是有很多问题。
a) 我加的实体层（Model）好像没用上，没什么作用
b) BLL层还有与数据库相关的代码，如DataSet、DataTable、DataAdapter等，Bll层与DAL层关系耦合太紧密。
c) 如果增加新查询、修改、增加、删除记录等操作，对数据库操作代码会很多、很大，应该考虑抽象一个类，封装对数据库操作代码里面不变动的部分，这样会实现代码的复用，减少重复。
d) 在各层之间返回实体类，为什么返回实体类？网上说了很多好处，我觉的主要是容易处理字段数量多的表，不至于，让函数带一大串参数。
e) 为了减轻DAL层复杂程度，是代码逻辑清晰，把DAL层里面接口拿出来了，新增IDAL接口层，然后，想了半天DAL里面DataAccess类，如果按用的时候划分等级，它应该在接口上面，所以，把这个类也拿出来了，又增一层DALFatory, 通过表接口访问不同数据库。
DALFactory层代码
IDAL层代码
SQLServerDAL层代码
SQLServerDAL层 sqlHelper辅助类
通过这个例子，对接口的好处有了一些理解，因为，开始我并没有使用接口，在这里的好处是通过数据库表接口，可以访问不同数据库，其实，实现访问不同数据库即它们都实现了接口中的方法，这才接口的关键，接口就是提供一些方法、行为，让不同类去实现，体现了多态性，结果是是代码、程序有了扩展性，可以应对需求的变化。当然，如果写程序之前，你确定需求是一定不会变的，那么可以不用接口也行。
接口的好处远不止这些，面向接口编程可以实现高内聚，低耦合，如上面例子，BLL层通过接口访问DAL层，使得更换数据库变的很简单，主要通过接口来实现切换，接口又用到了Ioc(Inversion of control)控制反转也叫做依赖注入(Dependency injection)+反射+XML应用程序配置文件等来更改不同数据库访问，实现这样的功能其实，我们用到了一个设计模式抽象工厂，对于设计模式我感觉就是太灵活了，怎么用都可以，关键在于用好，用得恰当，要解决的问题用这个模式是否合适，这应该才是正确应用设计模式。
做的过程中以及做完之后，感觉过程之复杂，思路有些乱，想画一下UML图，如果用图来表示，代码结构会非常清晰，下一步的任务就是画用例图、类图等等，等把图画的差不多了，再回来写代码。
总之，做了一个登录窗体后与不做之前对很多概念的理解是不同的，对有些概念，如接口、设计模式、封装和之前理解不一样了，米老师和学长们一直说：“学习真的是一个过程”现在也有点理解了，学习不能一蹴而就，需要在过程中理解，不过理解，不过学习，不过体会学习的过程。