最常见的架构就是三层架构啦！
1. UI层（用户界面）
就是给用户看的，负责展示内容和提供操作入口，比如按钮啥的。用户点一下，它就反馈结果。
2. 业务层（Business Tier）
这个是干重活的，主要负责数据处理，把加工后的数据给UI层或者数据层用。它又分为BLL（业务逻辑层）和DAL（数据访问层）。简单说，DAL专门负责跟数据库打交道，读写数据；BLL则负责调用DAL，对数据做运算和操作，同时响应UI层的需求。
3. 数据层（Data Tier）
顾名思义，就是存数据的地方，可能是数据库、XML文件或者其他形式。它只管数据怎么存，不管别的事。
这样就把显示业务数据分开了：
- UI层只负责展示，数据怎么算不用它管；
- 数据怎么处理交给BLL；
- 数据怎么存取交给DAL；
- 最终存储方式由数据层搞定。
各层之间比较独立，改动一个层时，其他层受影响的概率小很多，有时候只需要重新编译修改的部分就行。
开发人员一般只要搞定UI、BLL和DAL就行了，数据层通常靠操作系统或数据库管理系统来完成，咱们按规矩存取数据就好。
不过，光把项目分成DAL、BLL、WebUI三个模块，并不意味着这就是标准的三层架构！以下问题可以帮你判断：
1. UI层里有没有SQL语句或者存储过程？如果有，是不是只读操作，不会改数据？
2. 如果去掉UI层，你的项目还能通过API提供完整功能吗？
3. DAL能不能直接搬到别的类似项目里用？
4. 这三个模块能不能分别跑在不同的服务器上？
如果这些问题的答案不是全YES，那你的项目还不算真正意义上的三层架构。三层架构有一些必须遵守的原则：
1. UI层只能是个壳，不能掺杂任何业务逻辑。
2. 开发时要从业务逻辑出发，而不是从界面开始。BLL层得用面向对象的方式实现所有业务逻辑。
3. 数据层的设计要在一定抽象程度上做到系统无关，不管是SqlHelper还是ORM映射类，都得尽量通用。
就这样吧！
1. UI层（用户界面）
就是给用户看的，负责展示内容和提供操作入口，比如按钮啥的。用户点一下，它就反馈结果。
2. 业务层（Business Tier）
这个是干重活的，主要负责数据处理，把加工后的数据给UI层或者数据层用。它又分为BLL（业务逻辑层）和DAL（数据访问层）。简单说，DAL专门负责跟数据库打交道，读写数据；BLL则负责调用DAL，对数据做运算和操作，同时响应UI层的需求。
3. 数据层（Data Tier）
顾名思义，就是存数据的地方，可能是数据库、XML文件或者其他形式。它只管数据怎么存，不管别的事。
这样就把显示业务数据分开了：
- UI层只负责展示，数据怎么算不用它管；
- 数据怎么处理交给BLL；
- 数据怎么存取交给DAL；
- 最终存储方式由数据层搞定。
各层之间比较独立，改动一个层时，其他层受影响的概率小很多，有时候只需要重新编译修改的部分就行。
开发人员一般只要搞定UI、BLL和DAL就行了，数据层通常靠操作系统或数据库管理系统来完成，咱们按规矩存取数据就好。
不过，光把项目分成DAL、BLL、WebUI三个模块，并不意味着这就是标准的三层架构！以下问题可以帮你判断：
1. UI层里有没有SQL语句或者存储过程？如果有，是不是只读操作，不会改数据？
2. 如果去掉UI层，你的项目还能通过API提供完整功能吗？
3. DAL能不能直接搬到别的类似项目里用？
4. 这三个模块能不能分别跑在不同的服务器上？
如果这些问题的答案不是全YES，那你的项目还不算真正意义上的三层架构。三层架构有一些必须遵守的原则：
1. UI层只能是个壳，不能掺杂任何业务逻辑。
2. 开发时要从业务逻辑出发，而不是从界面开始。BLL层得用面向对象的方式实现所有业务逻辑。
3. 数据层的设计要在一定抽象程度上做到系统无关，不管是SqlHelper还是ORM映射类，都得尽量通用。
就这样吧！