三层架构

        对于一个刚入手编程的菜鸟来说，都想编写一个可读，可维护，性能高的程序，我也如此，在面临Boss的项目时候，拿起来立马就开始编写主要功能，然后环形拓展，类似快速开发模型，慢慢的就发现在修改某些功能时候是如此的繁琐，肯定的说不是一个好的程序员；当你拿到一个Project，你需要的是设计而非噼噼啪啪敲代码，设计好的架构是至关重要滴，在此劝诫每一位新手。

        那么入如何能有效的设计出来程序架构呢？即“高内聚，低耦合”的程序模块呢？我弱弱的在此推荐三层架构，其来源于MVC，核心是保持三层之间的相互独立，在对其功能修改时，可尽量保持三层架构不变，避免了全盘否定，从头再来；换言之，即在修改某些功能时候知道从哪入手，不必要挨个寻找，修改的地方是必要的，不是尝试，这改改那改改，从而减少修改量。从开始学习到现在，不得不说，修改局部代码对整体的变动影响还是蛮大的，层次越多，修改的地方越多，也就是说Project越复杂，你需要的设计越复杂，因此带来逻辑和接口复杂性的增加。

So,what's 三层架构(3-Tier Architecture) 咧？查阅相关资料，统一回答如下：

三层架构包括：

1. 数据访问层（Data Access Layer, DAL）：它的各个函数完成的仅仅是对数据文件的操作，不管其他操作；然后负责将底层数据传送到业务逻辑层

2. 业务逻辑层（Business Logic Layer， BLL）：处理数据访问层传送的数据，主要负责对数据层的操作，把一些数据层的操作进行组合，并实现业务逻辑

3. 表示层（User Interface， UI）：不处理任何业务，负责显示与实时更新，即接受用户的请求，以及数据的返回，为客户端提供访问。
其三之间的关系如下图：

在百度百科里说设计三层架构需要几个原则，在此借用一下：

⒈ 最关键的，UI层只能作为一个外壳，不能包含任何业务逻辑(BizLogic)的处理过程
⒉ 设计时应该从BLL出发，而不是UI出发. BLL层在API上应该实现所有BizLogic，以面向对象的方式
⒊ 不管数据层是一个简单的SqlHelper也好，还是带有Mapping过的Classes也好，应该在一定的抽象程度上做到系统无关
⒋ 不管使用COM+(Enterprise Service），还是Remoting，还是WebService之类的远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在设计的时候要做这样的考虑，更远的，还得考虑多台服务器通过负载均衡作集群。

        因此在面对Project时，仔细想想是否需要设计成三层架构，不要照搬，切记，三层架构是面对复杂的项目提出的，遇到小的项目就可以简单面对了。
       相关代码在后续的博客中加入，请各位大神指教。
       转载请标明出处http://blog.csdn.net/jasonhds/版权所有，翻版必究~谢谢合作！