多層架構中數據訪問層之我見

學習多層架構有一段日子﹐一點點個人理解﹐當然其中可能存在偏頗﹐歡迎各位拍磚批評﹗
首先是數據訪問層﹕
1﹑數據訪問層的主要目的就是屏蔽上層業務邏輯層與底層數據訪問﹐使業務與數據操作無關。因為數據訪問層在中間的嘛﹐呵呵﹐這個極好理解吧﹗ 這一層主要是針對數據表寫的﹐可以一個表一個類﹐也可以將關系比較緊密的主子表一個類。我常將這個理解為"數據建模"﹐不知各位是否認同。書上叫做數據持久層吧﹐意思就是業務邏輯層有一些處理完的資料是要持久保存下來的，不能讓它在記憶體中隨之而丟失，這時候作為一個享受服務的身份業務邏輯層就將資料交給資料持久層。它不管資料持久層如何去保存這些資料，反正就要求以後訪問資料持久層拿回資料時要能夠拿得到。之後資料持久層再根據業務邏輯的特性考慮自己的實現方式，是採用關係型數據庫還是採用層次型資料庫，這就是細節問題了。
2﹑為什么使用數據訪問層﹐我打個比方問你一句﹕假如你現在使用的是MS SQL資料庫，如果某天一新客戶要求使用Oracle，你是願意將整個系統重新寫一遍呢還是只重新寫一個資料訪問層？當然如果你的系統不會遇到這樣的情況，確實沒有必要設計資料訪問層，這樣設計的目的也是為了以後更好的擴展。

最后﹐貼一點書本上的老調﹐個人覺得很有用﹐供大家品品﹕
分层式结构究竟其优势何在？Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。

概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。

一 个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如UI人员只 需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确 认，开发进度就可以迅速的提高。

松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖， 谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明 显。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。

进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。

“金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。