多层架构的解释

系统的分层设计带来的好处是显而易见的，由于层间松散的耦合关系，使得我们可以专注于本层的设计，而不必关心其他层的设计，也不必担心自己的设计会影响其它层，对提高软件质量大有裨益。而且分层设计使得程序结构清晰，升级和维护都变得十分容易，更改层的具体实现代码，只要层接口保持稳定，其他层可以不必修改。即使层的接口发生变化，也只影响上层和下层，修改工作量小而且错误可以控制，不会带来意外的风险。系统的分层设计，估计没几个程序员不知道，但是在一些大大小小的项目里，能真正做到的，恐怕不多！ 有些程序员或系统设计人员认为对于一个小项目，没有必要这么做，但我认为除非你对这个项目有非常的了解，确保它不会在以后增加新的功能，你或许勉强可以这样做，但这种情况很难保证，现在的应用系统越来越复杂，我们一定要做好应付各种变化的准备。在实践中，很多的系统都用到了分层的设计，然而在遇到一个需求的变更时，设计的脆弱仍然不能完成这个变更的需求，我们以常见的三层结构来分析一下： 1、UI层：我说的这个UI层可能包含了很多的概念，除了大家都知道的window form和web form，它还包含了那些可能没有用户界面的用户接口，像window service，web service以及.Net remoting service等的入口，它们都可以看作UI层，而UI层应该只和业务逻辑层发生关系。有些系统尽管划分了层次，但却将部分的业务逻辑放在UI层，这就增加了UI层和业务逻辑层的耦合度，不利于UI层的增加或变换，因为如果需要再增加另外的一个UI层，而新增加的层中又包含了原有UI层的部分功能，这时新的UI层不得不再一次实现同样的功能，如果已实现的功能不符合要求，需要修改时，又不得不在已实现了的多个UI层中进行改动，这样不但增加了工作量，而且增加了出错的可能性。 2、业务逻辑层：所有的业务逻辑处理的集中地，它为UI层提供服务。比如一个购物系统，当客户下了订单时，一般应该做这些事情：1、检查提交的数据的合法性；2、验证客户信息；3、检查商品信息，比如商品是否存在，是否有足够的库存等；4、提交订单。这四步对于UI层来讲是透明的，就是说UI层只调用业务逻辑层的一个相应的方法，而不是亲自完成这四步功能，因为这四个步骤实现了一个完整的业务逻辑，它们不可以分开。如果需要公开一个Web Service，供客户提交订单，Web Service的实现也只是简单的调用业务逻辑层的一个相应的方法。 3、数据（库）层：这一层才真正的实现了数据的存取，它为业务逻辑层提供服务。在这一层上不需要关注业务逻辑，只是存取数据。对于确定只用一种数据存储方式来讲，这些就足够了。但在一个分布式的系统中，这种简单的实现是不够的，因供存取数据的不一定来自数据库，也可能来自其他数据文件，比如XML、Excel等，不同的数据库之间也有很大的差异，这些异构的数据对业务逻辑层来讲都是透明的，业务逻辑层没必要了解数据存取的细节。那么如何才能实现这种结构？通常的办法是为数据（库）层提供一个接口，业务逻辑层只是调用接口所约定的方法，这样通过接口就可以实现很多异构数据的存取了。 如果能严格的区分这三个层次的功能，那么设计的系统将大大降低了层之间的耦合度，非常利于扩展和维护，而且还很容易分配更为合适的人工作在不同的层，增加了人员的利用率，好让他们发挥自己的特长。 在这儿还需要提醒的一点是，如果你所用的数据库系统支持存储过程或者类似的功能，就一定要用存储过程而不是将SQL语句嵌入到程序中（嵌入的SQL语句增加了系统扩展和维护的难度），大家都知道使用存储过程有以下优点： 存储过程已在服务器注册 存储过程具有安全特性（例如权限）和所有权链接，以及可以附加到它们的证书 用户可以被授予权限来执行存储过程而不必直接对存储过程中引用的对象具有权限。 存储过程可以强制应用程序的安全性 参数化存储过程有助于保护应用程序不受 SQL Injection 攻击。有关详细信息，请参阅 SQL Injection。 存储过程允许模块化程序设计 存储过程一旦创建，以后即可在程序中调用任意多次。这可以改进应用程序的可维护性，并允许应用程序统一访问数据库。 存储过程是命名代码，允许延迟绑定 这提供了一个用于简单代码演变的间接级别。 存储过程可以减少网络通信流量 一个需要数百行 Transact-SQL 代码的操作可以通过一条执行过程代码的语句来执行，而不需要在网络中发送数百行代码。 除了这些优点外，还有一个优点：可以让一些更为专业的数据库人员去优化SQL语句（如果SQL语句嵌入在程序中就会比较困难，首先专业的数据库人员并不一定是专业的程序员；其次SQL语句很多都是拼接的），现在很多的程序员并不都是专业的数据库人员，对于大型的系统，我想更有这个必要。