.NET 分布式架構開發實戰之二 草稿設計
核心提示：本篇之所以稱為草稿設計，是因為設計的都是在紙上完成的。反映了一個思考的過程。
前言：
本篇之所以稱為草稿設計，是因為設計的都是在紙上完成的。反映了一個思考的過程。
本篇的議題如下：
1）。 第一個數據層草圖的提出
2）。 對數據訪問層的思考
3）。 第二個數據層草圖的提出
1.數據層草圖的提出
Richard開始著手設計，一開始他沒有就立刻在自己的計算機開始敲代碼。而且采用筆＋紙開始構思。
因為他認為：寫程序不是什么時候都得上機，腦子里面想什么的才是最重要的，往往很多時候，在設計程序時，首先在頭腦中就已經把整個功能已經實現了，甚至代碼的詳細編寫都已經在頭腦中走了一遍，并且在頭腦中”運行，調試”了。
開始設計了，因為這次Richard想要提出一個比較好的架構，一個比較強大的企業級的架構，所以參看成功的一些案例是很有必要，Richard也想到了微軟best practice的那些推薦的架構組織方式和建議。
之后，Richard的第一個草圖就出來了：
一個架構組織方式的提出，不是隨隨便便就提出的，新的架構的設計和提出首先必須要明白你要解決哪些問題，而且也不要”過度設計”。。可能在起初會參看一些別的設計架構，甚至是模仿它們，但是隨著思考的深入，那些表象的東西就會逐漸的被拋除。
同時也開始設計的時候，沒有說一定要立刻就要設計出一個很強大的東西出來，對架構設計的能力也是在慢慢的演化和思考過程中提升的。
2. 對數據訪問層的思考
在解釋為什么架構要像上面那副圖進行設計之前，我們首先來討論一些之前項目問題：
對于數據訪問層的問題：
1. DAL很依賴Linq生成的實體。可以說在之前的項目中，在數據訪問層能夠使用的技術就已經”釘死”在了Linq上。這里不是說Linq不好，而且強調在DAL的訪問技術的選擇的余地已經沒有了，不靈活。
a） 在架構的設計過程中，就需要考慮到以后技術的轉變和更換，可能在項目A中采用Linq to sql，但是在項目B中就采用Entity Framework。因為我們的目的就是要開發一個比較靈活的通用架構，能夠支持不同就數據訪問技術。可能以后的項目都只是用一種訪問技術，但是最為架構的設計者，特別是希望從架構最后能夠演化到Framework， 那就要為更換技術預留接口。
2. 在DAL中沒有很多的異常處理等底層機制。
a） 在項目設計的過程中，有些底層的機制是幾乎每一個邏輯都要用到的：異常處理，日志跟蹤，緩存機制，事務機制，安全驗證機制。當時在之前的DAL中是沒有的。可能現在你認為有些機制不是需要的，或者不明白為什么需要。
因為一個強大的軟件，不能隨隨便便就因為某些異常或者錯誤就崩潰了，也不可能就是一大堆代碼的堆砌。上面所提到的有些機制：如異常，日志，它們的價值很多時候在軟件維護的時候體驗出來。根據日志記錄，可以查處軟件哪里出了問題，如是數據庫斷了，還是哪個操作流程導致了問題。 而有些機制是在運行時體現價值，如緩存，驗證，事務。
但是在使用這些底層機制的時候也要權衡，綜合的考慮，如緩存機制，就得明白那些數據要緩存，緩存在哪里，緩存數據時候要加密，緩存多長時間，如何刷新過期了的數據。等等，很多東西要考慮。
3. 數據來源僅僅只是考慮了數據庫。其實這個問題不是之前的項目的一個問題，但是這里有必要提出。
a） 一般在我們開發項目的時候，數據的來源很多時候都是數據庫，我們直接操作數據庫就行了，但是還得考慮一個問題：如果我們的項目沒有自己的數據庫，我們的數據來源是來自其他的公司或者服務接口，怎么辦？作為架構的設計者，是需要考慮這些的。
没有评论:
发表评论