??在進行程序開發(fā)和設計時我們常常提到分層的概念，但是怎么樣的分層才是好的分層呢，在這篇我談談我在如何分層這個問題上的一些體會，和大家探討一下
為什么要分層
??系統(tǒng)要分層主要我覺得主要是有兩個原因：
- 存在著不同的利益相關者，有著不同的關注點
- 軟件中的不同的部分，有不同的變化頻率
??上圖是一個常用的三層架構，其中，用戶界面層面向用戶，變化頻率高；業(yè)務界面層面向業(yè)務，變化頻率相對較低；數(shù)據(jù)庫訪問層面向基礎設施，變化頻率低。這樣的分層帶來有效地隔離了業(yè)務邏輯與數(shù)據(jù)訪問邏輯，使得這兩個不同關注點能夠相對自由和獨立地演化
怎樣才是好的分層設計
??分層能降低軟件設計和開發(fā)復雜度，但是不恰當?shù)姆謱訁s會導致軟件的復雜度的提升，那不好的分層有一個基本的特征就是：相鄰的分層間在功能上很相似，增加的層次沒有系統(tǒng)帶來明顯的能力，常常表現(xiàn)為方法透傳，及新增加的層次僅僅做了很少的事情，及將相關請求發(fā)送到了下層去進行處理，如下面的代碼所示：
public class AnimalServiceImpl implements AnimalService {
private static Logger logger = LoggerFactory.getLogger(AnimalServiceImpl.class);
@Inject
private AnimalDao animalDao;
@Override
public Animal queryById(long id) {
return animalDao.query();
}
@Override
public boolean update(Animal animal) {
return animalDao.update(animal);
}
@Override
public long insert(Animal animal) {
return animalDao.insert(animal);
}
........
}
?? 這種分層方式在我們的日常編碼中經(jīng)常遇到，服務層僅僅是將用戶界面的調用傳遞給數(shù)據(jù)庫訪問層，僅僅是方法和參數(shù)的透傳，這種透傳帶來的最大的問題就是這種分層沒有為軟件帶來任何的價值，如果這個層次中都充斥著這樣的代碼，這個層次與其相鄰的層次很相似，一般會把這個分層認為是一種架構的壞味道
如何做到好的分層設計
??說到分層，我們一般都會提到iso網(wǎng)絡的七層模型，如下圖：
??從上圖中大家可以看到這七層模型中，每一層都其特定的功能，可以說是功能和其提供的價值都是極為明確的，所以如何能做好分層，就是要使每分離出來的層次都有明確的功能和價值
做好分層需要避免方法的透傳
??方法的透傳在大多數(shù)場景下，都有一種沒有增加價值，反而增加了壞復雜性的壞味道，除了向dispatch這種分發(fā)的場景，往往我們可以通過如下方法來解決方法的透傳調用：
- 直接調用方法的最終提供者，這個有時會破壞層次之間的劃分，需要綜合考慮
- 將涉及的函數(shù)功能做重新的分布，對此功能所處的層次就行重新的考慮
-
進行層次的合并，考慮是否層次的劃分出現(xiàn)的問題
??在java中，I/O 處理的這套的架構體系遭到的批判是很多的，在I/O 處理中，java使用的裝飾模式，實現(xiàn)了方法的透傳調用，雖然在每個裝飾層次中也提供了一些能力，如：buffer，但是提供的功能相對較少，并且在IO中，提供buffer的能力應該是絕大部分場景都需要的，所以我們對其進行功能的合并，而不是單獨的將其功能實現(xiàn)在不同的層次中，增加了整個系統(tǒng)的復雜性
java IO
做好分層需要避免調用參數(shù)的透傳
??調用參數(shù)在各個層次的透傳，會導致一些層次的接口需要了解不是其層次應該處理的知識，這樣就會導致增加系統(tǒng)不必要的復雜性，一般來說們可以通過如下方法來解決函數(shù)的透傳：
- 使用全局變量，這樣每個層次都可以訪問到這些參數(shù)，避免了參數(shù)在各個層次的透傳
- 使用context來傳遞參數(shù)，context通過參數(shù)在各個層次中傳遞，每個層次只需要訪問自己所需要的，不會引入不必要的復雜性
總結
??做好分層，我們需要思考各個層次的功能和價值，就像 Robert C.Martin提出的尖叫架構一樣，我們也需要尖叫的分層
注：相關圖片來自于互聯(lián)網(wǎng)
