本篇主要講述項目的一些背景。
新人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的，而是用來解決問題，這就是技術的價值。
本系列文章就展示整個構思，設計，實現的過程。本系列文章所要開發的項目的價值可能不大，本系列文章的價值在於架構的思考和設計過程，一步步的演化過程。
出處：http://www.cnblogs.com/yanyangtian
