名词解释
架构：架构一般是针对整个系统的，并非针对某个单独的问题（单独问题可以用模式等来解决）针对整个系统的”一个蓝图”，对系统的抽象。
模式：软件开发中遇到的一些特定问题，前人总结出来特定的经验、解决方法。
框架：架构设计、模式应用的经验积累的具体代码实现，方便以后的复用。
三层
表现层UI（User Interface）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
业务逻辑层BLL（Business Logic Layer）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。（备注：又称领域层，常用于业务规则、数据访问、合法性校验）
数据访问层DAL（Data Access Layer）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。（领域对象：crud）
（新的：逻辑层就像房屋中介，租房买房更快捷了，但消耗的钱也更多了。）
优点：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期维护的时候，极大地降低了维护成本和维护时间
缺点：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了开发成本。
规则：
三层结构的程序不是说把项目分成DAL,BLL,WebUI三个模块就叫三层了，下面几个问题在你的项目里面：
⒈ UILayer里面只有少量（或者没有）SQL语句或者存储过程调用，并且这些语句保证不会修改数据?
⒉ 如果把UILayer拿掉，你的项目还能在Interface/API的层次上提供所有功能吗?
⒊ 你的DAL可以移植到其他类似环境的项目吗?
⒋ 三个模块，可以分别运行于不同的服务器吗?
如果不是所有答案都为YES，那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则：
⒈ 最关键的，UI层只能作为一个外壳，不能包含任何BizLogic的处理过程
⒉ 设计时应该从BLL出发，而不是UI出发. BLL层在API上应该实现所有BizLogic，以面向对象的方式
⒊ 不管数据层是一个简单的SqlHelper也好，还是带有Mapping过的Classes也好，应该在一定的抽象程度上做到系统无关
⒋ 不管使用COM+(Enterprise Service），还是Remoting，还是WebService之类的远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在设计的时候要做这样的考虑，更远的，还得考虑多台服务器通过负载均衡作集群
所以考虑一个项目是不是应该应用三层/多层设计时，先得考虑下是不是真的需要? 实际上大部分程序就开个WebApplication就足够了，完全没必要作的这么复杂. 而多层结构，是用于解决真正复杂的项目需求的。
三层结构示图
三层与MVC的区别
同样是架构级别的，它们有什么相同点和不同点呢？这篇文章讨论一下它们的异同点。希望能帮助读者理解其中的玄机。
其实它们相同的地方在于他们都有一个表现层。
但是他们不同的地方在于其他的两个层。
首先先解释一下MVC。V即View.是视图的意思。C即Controler.是控制器的意思。而M即Model，是模型的意思。这三个里.最不容易理解的应该是Model.就是什么是Model，而为什么叫Model。我先不说为什么叫Model，先解释Controler。
Controller是控制器的意思，所谓控制器，就是将用户请求转发给模型层，经过处理后把结果返回到界面展现的一个中间层，那么Controler到底管什么工作呢？先不说.先来看下在Java Web中这三个层一般的定义，一般在Java Web里，JSP充当V，Servlet充当C,JavaBean充当M，这里的Servlet管什么工作呢？接受输入，转到Model层去处理，处理结果保存后转发到JSP，然后展现数据。所以它的功能就是控制器的基本功能，它就管转发，在V和M之间转来转去。
再来说说M，即Model，在Java Web里说的是JavaBean，我认识的很多人都把JavaBean误认为是实体类，其实JavaBean有比实体类更丰富的定义，在JavaBean中除了其属性和字段，还可以有行为及其事件，JavaBean可以理解为普通Java对象。Java普通对象，就是符合Java规范的所有对象，这和实体类完全是两回事。所以，我认为在MVC中。业务逻辑和数据访问应该放在Model层，也就是V负责展示数据，Controler除了转发不做业务逻辑。真正的逻辑事务，数据访问，甚至算法都放到Model去。
再说三层架构。三层其实很好理解，界面，业务，数据访问，就这三个，从字面都可以理解出它们的意思。我要说的是它和MVC的区别。在三层架构中没有定义Controler的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。
当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是已实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。不一样的概念。虽然名字一样。
SqlHelper类
SqlHelper.cs是多年前微软出品的一个使用ADO.Net方法对SQL Server数据库进行操作的封装类。而我们自己手写的SqlHelper类同样是对数据库访问方法的一个封装类库，让我们在访问数据库的时候可以很方便地调用其中封装的方法，省略了很多重复劳动。在声明SqlHelper的时候,我们一般会声明为一个静态类，不使用静态类的话有可能产生一些未知的错误（苏老师说微软说的）。
这个类中我们常用的方法如下：
- ExecuteNonQuery(): 执行简单的无返回值的查询。
- ExecuteReader(): 使用DataReader读取数据。（注：少量数据的情况下使用 SqlDataReader的效率高于使用Dataset）
- ExecuteScalar(): 返回结果集中的第一行第一列，相当于返回单个值。
- ExcuteDataSet (): 返回Dataset的查询，相当于返回一个数组。
除此之外，我们根据需要以及兴趣也可以再增加一些其他的方法，对其进行修改以及扩展。
三层使用及案例
第一部分：
登陆：对T_Seats表的查询操作
修改密码：对T_Seats表的修改操作
第二部分：
对T_Area表的删除操作（主要知道递归删除算法）
第三部分：
注册（需要注意地方：1、添加操作需要output inserted.cc_AutoId 2、添加之前，还需要验证当前用户是否已经存在，用到了exists()做判断）
第四部分：
建多个类库，实现对T_Seats表和TblPerson表的操作，实现CRUD
- Sql语句：select cc_autoId,cc_loginpassword,cc_userName from T_Seats where
- 编写数据访问层（返回值是一个Model，参数是loginId）
- 写model的时候写完全（也就是所有T_Seats中的列名都写成属性的形式）
- T_Seats model=null;
- return model;
- 由于在读取数据库中是数据的时候，里面只能够读取到一条用户名的信息，所以用if（reader.Read()）
- 编写业务逻辑层
- 首先需要查询，就用到了数据访问层中的信息，需要先实例化一个数据访问层“类”
- CommonHelper中使用static（静态类）
- 表现层需要做的事情
- 采集数据：界面框中的数据
- 然后调用业务逻辑层
- 得到业务逻辑层的返回值信息
- 由业务逻辑层的信息进行相应的操作（9:26两out参数（why?））
- 表现层中写GlobalHelper中的autoId的作用
修改密码：（思路）
1.校验两次数据密码是否一致（不需要sql语句）
2.校验旧密码是否正确（根据autoId来判断旧密码是否正确）
3.修改密码（如果旧密码正确的话，再开始进行 修改密码 操作）
在BLL中的操作
- 首先判断返回给UI层的结果：用枚举类型来写
- 得到了返回值类型
- 编写修改密码的方法，确定参数
- 省市加载到treeview上
- 三层删除当前节点下的所有节点（1在BLL层先写一个删除方法；2然后使用递归删除方法；3在递归删除过程当中，又调用了加载过程当中的递归加载方法）
项目的操作
分多个项目的增删改查
配置文件放在UI层（表现层）
里面的都写成类库类型
model中最好和表中的列一样
多个项目之间需要在”引用“当中添加引用
