談談最近參與開發的一個SAAS軟體的架構

最近有幸參與了一個生管軟體的SAAS開發，也做了兩周的編程。總體感覺有可取之處，但更多的是感覺運行速度慢，開發效率低。下面就簡單分析一下。

軟體採用.net 3.5，開發工具用VS2008，資料庫sql 2005。系統也進行了分層，有ASP.NET表現層，業務管理層，資料訪問層，資料庫本身也算一層吧。

 

在表現層和業務層之間用了Microsoft.Practices.Unity工具，用於在表現層調用業務管理層時，能實現一個介面轉換。在表現層，編程時使用業務管理層的對象所對應的介面，程式運行時，Unity工具會實現真正業務對象的調用。表現層和業務層之間傳遞資料的是所謂的“領域模型”，一般命名成xxxInfo類，但我感覺更象個“實體類”。

 

資料訪問層是通過ADO.NET Entity Framework，微軟最新推出的一個所謂ORM的工具，當然，在VS中拖入表結構，再設定一些實體模型，資料模型的對應關係，就能全部產生資料的訪問，代碼幾乎不用寫。

 

業務層，業務管理對象，一般命名成ManageXXX主要實現查詢，新增，修改，刪除（CRUD）的封裝，如新增或修改操作時，先調用資料庫成的EF建立一個EF的實體模型對象，如果是新增就建立一個新的，如果是修改就根據ID撈一個，再將UI層封裝過的Info對象，欄位一一映射到實體模型對象，調用EF的SaveChanges方法。當然取資料時，是從EF實體模型一一映射到Info對象。

 

總體的架構就是這樣。我以個人感覺來說說這樣做有什麼不好。

 

資料庫EF是微軟剛推出的技術，看了MSDN，感覺是不錯，但真正用起來，我感覺沒多少人用得好，大家還是對傳統的ADO技術比較熟悉，一些特別的功能實現上，在業務管理類中，用了一些EA LINQ的文法，EA　實體文法，EA的SQL用得不多，訪問EA就這三種技術，因為技術上不熟悉，會導致有時候感覺效率狂底，反正我開發起來，第1次操作一條記錄都是非常慢的。比如更新一個訂單，假設訂單主表關聯的其它表比較多，如客戶，業務員，付款條件，幣種，匯率，運送方式等等之類的，或取這個對象時，如果沒有“消極式載入”，不知要載入多少個對象，還有萬一對象設計的不好，造成迴圈載入就麻煩了。用了新技術，使得新進人員跟上的速度慢了，真擔心以後的效率問題。

 

另一點，最主要做得差的地方，就是所謂的領域模型xxxInfo類。我們心目中物件導向技術真正的領域模型，是一種對象包含相關的對象，而現在的領域模型，裡面就是對資料庫欄位的簡單set,get，偶而加一些介面上用到的對象資訊，所以，我說這是一個實體類還差不多，最令人不解的是，這些Info類裡的欄位，是原始的欄位，而EF調的時候卻是對象。比如，Order表裡有CustID欄位，EF裡是Order.Customer，而Info類卻是CustID。這樣，取資料時，要傳換成Order.Customer.CustID。寫資料時，要new Customer(CustID)，就是這個意思了，感覺不是在做無用功嗎，取資料時，Info類只要CustID，現在我估計EF又從Customer表根據ID得到一個Customer資料對象。 寫資料時，Info類裡只有CustID，為了滿足EF的儲存需要，又要根據CustID得到一個Customer資料對象，再賦給Order資料對象的Customer對象，因為他們存在關聯啊。感覺就是在“本末倒置”。

 

最最感覺不爽的就是開發效率狂底。大家想想為了實現一個功能，我們要手工寫多少功能。Info類要手寫，從資料模型轉成Info類的方法要手工寫，從Info類轉成資料模型的方法要手工寫，業務管理類的介面要寫手工定義好，業務管理類的實作類別要手工寫好，當然業面的程式更不用說了，一個表20,30個欄位是正常的，看看吧，一個功能要寫多久，上周我寫一個銷售訂單的功能，花了4天時間，而且還有很多代碼和功能是參照別人採購訂單的，複製了不少代碼，修修改改才勉強完成。而且開發體驗是相當的不爽。

 

因為手工寫的地方太多，直接導致將來出問題的地方的機率會太多，一個地方考慮不到，重新編譯調試要花多少時間，唉，無耐啊。

 

近段時間，我又在看了CSLA.NET的架構，感覺這個架構真是太好了，移動業務對象，分布式布署，特別還有一些代碼自動產生的工具，感覺有了標準，代碼自動產生，開發效率快，功能強大，開發體驗絕對不一樣。等下翻譯一篇，代碼自動產生文章給大家看看，昨天晚上試用一下這個軟體，不是一般的強大。而且還是開源的，媽的，服了。