前言：在开发的时候我们常常讨论有关设计模式方面的东西，也学习了不少设计模式，而且也可以写出设计模式的一些演示的代码，但是在真正开发的时候，有时却显得很无能为力，而且觉得用不用都差不多，就算是勉强的用了，也不见得把代码改善了多少。
用不用设计模式，很多时候不是我们说了算的，因为很多的设计，在我们上面的一些人员就已经敲定了的，程序员一般都只是开发一个小小的模块而已，但是即便如此，在我们有限的范围内，我们还是可以有一些发挥的！下面我们就来谈谈一些开发方面的东西！下面来看看从分层到模式的的自然的过渡！
首先看看数据访问层。
数据访问层（Data AccessLayer，后面简称DAL），一般是对数据库执行查询，更新，插入和删除操作的代码，是最接近数据库的代码，它必须了解数据库的所有的细节，如表结构，字段名称，存储过程等。在以前我们开发的小小的程序中，经常的做法就是双击按钮进入事件，开始写数据操作代码，当然这样的程序大家现在不会写了，原因很简单，最直观的的原因就是以后代码不好改，到处找SQL的链接操作语句等。说的专业一点就是数据层和业务层，UI层杂糅在一起，职责不清。所以我们就要分开这些，所以就开始有分层的思想了，但是怎么分，可能我们刚开始不是很清楚，也知道设计模式可以解决，但是如果我们立马向设计模式奔，有点唐突：思想可能还没有那么快的过渡。但是，起码我们知道：分，肯定是有好处的。
下面就看看“分”的好处：
1.开发用户界面的人很开发数据访问代码的很多的时候不是同一个人。用户界面开发人员可以忽略与数据库相关的大部分的内容，但是他还是能够为数据库提供用户界面的，因为他起码知道最后数据在界面的表现的效果的。
2.一些获取数据的查询语句会被不通的页面使用，如果直接放入，如aspx页面中，以后的修改可想而知，如果把这些数据操作的代码放到一个地方，如一个专门的数据操作模块中，别的优点先不说，起码以后改起来方面。
3.将数据操作代码硬编码在页面中，以后移植新的数据库，如从SQL SERVER 到DB2，不方便。
下面看看过渡的思路。
现在我们起码知道已经把数据操作代码放到单独的地方。但是需求多变，代码也要应对变化，所以，对于数据操作代码而言，要考虑一下以后的数据库的更改。初步的思维就是判断：把现有的数据库的访问代码都写一份，然后用if---else，没有错，只是很累，开发起码难度也不好说。万一客户说他不喜欢数据库，而是喜欢用别的数据存储方式存储数据，如XML，以前的代码的if---else中要加一段了。我们都不乐意。
要寻求别的方法了，大家知道继承可以来抵御变化，那么就开发一个抽象类，使得我们现在的程序调用这个抽象类，真正做事的是他的子类。把我们的程序比成一个人，他要吃东西，一会吃这，一会吃那，烦！我们就把餐票给他，先哄着他，等真正吃的时候，就用餐票换吃的。
上面我们谈的是给抽象类，其实接口也行，但是我们的数据操作很多都有一定的共性的，就是可以重用一些代码的，那么我们就抽象类最好了。
那么我们的设计就如下图了：
现在的代码设计就好了一点。其实这就是在实现一种设计模式，一般说是策略模式，微软中也称provider提供程序模型设计模式（如MemberShip等就是这样的）。
现在我们的代码起码可以访问很多的数据库了，但是还是有问题:我们从页面接受的数据要验证，要经过一定的处理（专业的说法就是业务逻辑处理过程）才能放入数据库。现在我们可以把也写验证等代码写到DAL中，或者也不写在DAL，哪里需要就哪里写。如果是前者，在DAL中确实是可以放入一些验证等代码，如果全部放，但是这样岂不又和之前的那种代码一样啦！如果是选择后一种，问题很前面的一样了：到处放置，修改起码到处跑！所以，我们有要用一个专门的类或者模块来封装业务处理！这样三层结构就出现了。一种自然的思考，模式的自然使用。
现在结构如下：
现在改分离的是分离了，但是似乎BBL层和DAL合作还是有点问题！确实！
因为我们一般都是看到的下面的三层结构图：
不急，因为我们说了：模式到架构的自然过渡，现在还没有到那一步，因为要真正的把上面的图用我们自然的理解来完成，也就是说，不是硬是用架构来套，框，然后我们就给告诉自己：哦，那就是三层架构，其实这理解是不够的。等到我们谈论下一个话题：DataSet和自定义实体就可以了！
谢谢大家！