[原創].NET 分佈式架構開發實戰之一故事起源

時間 2019-11-30

原文原文鏈接

.NET 分佈式架構開發實戰之一故事起源html

　　前言：本系列文章主要講述一個實實在在的項目開發的過程，主要包含：提出問題，解決問題，架構設計和各個邏輯層的實現以及新問題的出現和代碼的重構。本系列文章以故事的形式展開，並且文章列舉的不少項目的名稱，你們也不用太關心，不少都是虛擬的。緩存

　　系列文章連接:架構

[原創].NET 分佈式架構開發實戰之一故事起源app

[原創].NET 分佈式架構開發實戰之二草稿設計框架

[原創].NET 分佈式架構開發實戰之三數據訪問深刻一點的思考分佈式

[原創].NET 分佈式架構開發實戰之四構建從理想和實現之間的橋樑(前篇)ide

[原創].NET 分佈式架構開發實戰五 Framework改進篇post

[原創].NET 業務框架開發實戰之六 DAL的重構url

[原創].NET 業務框架開發實戰之七業務層初步構想spa

[原創].NET 業務框架開發實戰之八業務層Mapping的選擇策略

[原創].NET 業務框架開發實戰之九 Mapping屬性原理和驗證規則的實現策略

[原創].NET 業務框架開發實戰之十第一階段總結，深刻淺出，水到渠成（前篇）

[原創].NET 業務框架開發實戰之十第一階段總結，深刻淺出，水到渠成（後篇）

本篇主要講述項目的一些背景。

新人Richard被分配到了一個企業自動化信息管理項目組--Automation Information Management Project(後面簡稱AIM)，當Richard進入項目組的時候，這個項目已經開始了，項目的架構也已經在兩週以前構建好了--SOA架構，並且使用的主要技術也敲定了:WCF, Linq.

注：由於項目是首次採用"新技術"(由於之前沒有使用WCF,Linq，因此被稱爲新技術)，項目就這樣開始進行了。

半年以後問題就開始出現了(其實問題就一開始就出現了，只是你們還認爲問題不大)：由於當初在設計的時候，項目的架構是由項目組的其餘兩我的設計的，整個項目開發基本上就沒有采用面向對象的思想來開發，並且雖然在架構設計上分了：數據層，業務層，服務層，和UI層，可是各層以前是牢牢的耦合，能夠說是「牽一髮而動全身」：如數據訪問層稍微一改，業務層就跟着動，而後改變一層層的開始波及。

你們都開始以爲這樣很累，可是項目已經作到這個階段了，不可能重來。每次新需求一來，項目的的改動能夠說是天翻地覆。並且當初設計架構的那位仁兄也就項目一開始的一個月後就走了。

下面的圖就展現項目中的架構設計：

　　咋一看起來仍是不錯的，通常的架構都是這樣設計的。下面就開始講述它們之間的一些調用關係，看看有什麼問題：

數據訪問層：

     public class EmployeeDAL
    {
         public List < Employee > GetAllEmplyees()
        {
             // ...
        }
    }

其中Employee就是Linq生成的一個實體對象。

業務層：

代碼

     public class EmployeeBL
    {
         public List < Employee > GetAllEmplyees()
        {
            EmployeeDAL employeeDAL = new EmployeeDAL();
             return employeeDAL.GetAllEmplyees();
        }
    }

服務層：

代碼

     public interface IEmployeeServices
    {
        List < Employee > GetAllEmplyees();
    }

     public class EmployeeServices : IEmployeeServices
    {
         public List < Employee > GetAllEmplyees()
        {
            EmployeeBL employeeBL = new EmployeeBL();
             return employeeBL.GetAllEmplyees();
        }
    }

而後就是在客戶端生成代理，而後在UI中就調用了提供的方法。

如今一個最明顯的問題就是：把數據層的數據實體Employee一層層的傳遞，最後到了客戶端的UI代碼中，而業務層中的EmployeeBL基本上沒有起到什麼做用，只是起到一個過渡的做用，只是在Insert ，Update,和Delete的時候，對一些字段進行了相應的Check和Validation，如Email格式是否正確等等。其餘的一些流程的Check也是代碼的堆積，業務類很"弱"。

總的看起來就是"牽一髮而動全身"的效果。

並且在開發過程，分層的好處基本沒有體現出來。

在業務類的設計的時候，全部的業務類都顯得比較的"弱"，之因此這麼說，主要是基於這樣的一個思想：

都知道，在面向「對象」設計的過程當中，每一個類就比如一我的，實例化一個類就比如生成了一我的，這我的能夠在一出生就具有不少的能力(天生秉異)，如異常處理，日誌跟蹤，緩存，通用的驗證機制等等；也能夠一出生什麼都不會(或者只會作最基本的幾件事情)。以前的業務類實例化以後就生成一個很是普通的人。每一個類都得重寫不少的基礎代碼，說到通用那就只是copy代碼。若是想要使得新生成的類很強大，具有不少功能，在設計的時候可讓這些類繼承一個功能比較強大的基類。固然繼承只是實現方式的一種。

如今Richard已經被分到了另外的一個項目組(也是本系列文章要講述的一個項目，就稱爲項目進度管理系統—Project Process Management(PPM))，並且擔任了架構的設計和開發(以前的架構設計Richard沒有發言權)。有了前車可鑑，在新項目開發以前的幾個月，Ricahrd首先就開始了通用架構的設計，目的有兩個：

1.解決以前項目的問題：不靈活，不通用，每次都作重複性的事情等。

2.結合本身的考慮，開發一個Framework，使得開發更加的快速，靈活，強大。

其實在項目真正開始了以後，不可能給你幾個月的時間去設計架構的。其實在AIM出現問題以後，Richard就已經在構思若是開發一個通用的Framework了（」通用」--不表示就是處處可用，由於公司的一直是開發某一領域軟件的，好比如今的公司就擅長開發企業管理的一些軟件，因此開發出一個基於領域模型的架構和框架仍是有可能的）。Richard也想挽救AIM，因爲諸多緣由，想法終究只是成了想法。

在從AIM項目出來以後，Richard又開始了另外的一個項目的開發，名稱咱們暫時就虛擬的稱爲EMS(Employee Management System),EMS項目不是很大，公司解決讓Richard一我的開發這個項目。這個項目給了Richard不少的時間來考慮架構設計和Framework設計的時間，由於EMS項目不是很複雜，並且技術和進度都在掌控之中，在正常上班時間就能夠到時候按期交付。因此天天下班以後，Richard開始加班去構思Framework的設計，開發的時間越長，技術就應該沉澱的越多，如以通用類庫，組件的方式或者解決問題方案的文檔等出現。只有這樣，下次的開發才更加的快速。

3個月下來，EMS項目完成了。並且Richard設計的Framework也有了雛形。準確的說，還只能稱爲基礎架構基本完成。EMS沒有采用這個Framework來開發，由於Framework的設計和實現於EMS是同步進行的。

Richard內心是這樣認爲的：設計通用的架構，而後在項目中不斷的錘鍊，更新，產生出通用的代碼，而後演化爲Framework。只有設計出了本身的Framework，之後的開發纔有可能進入"光速開發"。

在這個項目開始之初，Richard就和其餘幾個組員討論瞭如何實現，同時也推出了本身開發的成果。商量以後，決定採用Richard的設計。

Richard在設計架構的時候，也參考瞭如今流行的一個Framework,如Spring.NET ,CSLA.NET, Nhibernate，主要吸取它們的一些思想，同時也分析了這些Framework對本身項目的利弊。並且認爲：沒有絕對萬能的技術，一個架構的實現須要在不少的因素之間權衡，技術不是用來show的，而是用來解決問題，這就是技術的價值。

本系列文章就展現整個構思，設計，實現的過程。本系列文章所要開發的項目的價值可能不大，本系列文章的價值在於架構的思考和設計過程，一步步的演化過程。　　

　　謝謝你們：）

　　下篇文章：.NET 分佈式架構開發實戰之二草稿設計

　　歡迎你們參加企業級項目開發團隊

　　版權爲小洋和博客園全部，轉載請標明出處給做者。

　　http://www.cnblogs.com/yanyangtian