今天看了一個篇關于架構的文章，略有所感，記錄一下。

軟件的架構基本是從一個原始需求出發，逐步構建可維護、更靈活的開發框架的過程，在這個構建過程中可能會逐漸的增加代碼的復雜度來滿足靈活性的要求，從這個層面來講，復雜度和靈活性天生就是對立的，怎么平衡二者的關系，考慮到時間復雜度，成本等等因素，則演變成一門學問，就叫軟件工程。以例子來說明呢會更加的清晰。

原始需求，基本辦法

我們經常會解決一個問題，比如說我們為了方便給自己定了一個任務列表，在記錄任務并可以查看任務狀態，還可以更改和刪除任務。解決這個需求不難想出一個數據表即可解決：

TaskList{

ID,--編號

Task,--任務名稱

AwokeTime,--提醒時間

State --狀態}

假定我是在WEB上操作，那么我想完成上述的幾個需求，只需要如下幾個方法

這是最基本的代碼了，在一個webform的頁面代碼中即可以完成所有需求了，通過webconfig配置來改變數據庫服務器的位置，通過一個簡單的ExcuteSql方法來執行所有對數據庫的操作。完成這個任務列表的功能，此時我們只需要一個aspx頁面即可，可為什么還需要分那么多層呢。

"我想在Winform也能用"

做軟件是為了給人解決問題的，人家就愛用winform的，怎么辦，再來個winform的吧，好的，到這里一個軟件有兩個展現方式，如何解決呢，你在想重新將代碼拷貝過來寫一個類似web的form嗎？那樣的話會出現兩個一模一樣的insert方法，update方法等等，以后改動的話，如果用戶有很多的界面展現方式，你要一個個都改嗎？那么代碼重用的問題出現了，將這些方法獨立出來，一份代碼web能用，winform也能用，如果想修改其中的某個方法，直接改就是了，代碼的唯一性，真不錯。

Win form? ----- web form

? \\??????????????????? //

insert,update,delete,search

代碼怎么組織呢，我們可以再寫一個類DB.CS，

里面有增刪改查四個方法，但是數據操作方法是獨立出來了，兩種用戶界面怎么辦呢？大家都知道，winform和webform是需要建立兩種項目的，那么我們只有將這個數據操作類在獨立出來的基礎上封裝成程序集共兩個項目共同引用了，于是，有了下面的轉變

---》》

這些簡單的建立了一個比較容易修改數據操作部分和界面部分的模型。

“我們決定采用Oracle來存儲數據”

軟件嘛，需求的變更早已不再是新聞，客戶可能已經有一個數據庫，為什么要再投入那么大的成本去適應軟件呢？試想一下，如果這個需求在前期并不明確，后期一旦改動我們開發人員將會多么被動，于是，我們可以做好預留，可問題是如果要改動數據操作方法，那么Architect.DB層的代碼都要改動，難道我們要將全部代碼重寫一遍嗎？不！我們是程序員，我們可以利用接口做另一套實現即可，如我們可以在某個地方輕松的將”SQL”改為”Oracle”即可讓程序更換數據庫多好啊,是的我們可以這樣做,一個接口,兩種實現,根據配置不同來選擇不同的實現方式。

這樣我們就可以根據配置的不同去動態的選擇不同的實現，以后如果再有ACCESS的需求也不用怕，直接在加個實現就可以了，在類UserDBO中我們可以根據不同的條件來實例化兩個不同的操作類。這樣就實現了不同的數據庫訪問類，通常我們不會將這兩種實現代碼放到一個類中，分開管理更加方便，于是便有了下圖

此時我們有了兩種數據庫的兼容方式,可以更加方便的更換數據庫了,但是實際開發中的數據庫訪問類要復雜的多,所以很多時候我們會將數據訪問接口和數據庫的操作類分開,變成這樣

這樣做的好處是各個層面上的代碼組織比較清晰,沒有纏繞到一起,非常便于對各層的修改.然而代碼組織到這里,是不是就完成了呢,剛開始看petshop的代碼時，我也覺得分層有些太多了，但后來真的接觸了比較多的開源代碼后，發現是有道理的，下一篇隨筆我將會繼續寫代碼組織方面的一些個人見解，包括業務邏輯，緩存和面向服務等等，希望能跟大家交流。

轉載于:https://www.cnblogs.com/wengyuli/archive/2010/06/23/code-organ.html

總結

以上是生活随笔為你收集整理的关于代码组织的一些看法（上）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。