服務訊息、業務實體以及資料實體

標籤：http   使用   strong   資料   問題   代碼   工作   sp   on   

名次解釋

 

服務訊息 － 分布式應用中各個服務之間傳遞的訊息，以WCF為例的話就是資料契約。

業務實體 － 業務物件模型、領域模型中和業務相關的實體。

資料實體 － 完全和關係型資料庫結構對應的資料實體。

 

問題

 

    今天有人在MSN上問了我一個問題引發了我的思考，問題大致如下：

最近在學習3.0的一些技術，比如WCF和LINQ，我嘗試使用這些技術寫一個分布式的新聞系統，系統的構架如下：

※     一個資料訪問層，其中包含了一個資料實體（自動產生的）。資料訪問層使用Linq To SQL進行資料訪問操作，並且把資料從資料實體轉化為領域模型中的業務實體。

※     一個商務邏輯層，以領域模型為核心。商務邏輯層使用Linq To Object再把業務實體轉化為WCF的資料契約。

這樣，整個項目中就有了三個實體：

※     資料實體 － 和資料庫對應的實體：新聞類、評論類；

※     業務實體 － 有層次及依賴關係的一些類：新聞基類、普通新聞類和重要新聞類分別繼承新聞基類，新聞基類持有評論類的彙總；

※     服務訊息 － 供WCF作為訊息的實體：還是新聞類和評論類，和資料實體相比少了一些不必要的屬性。

等新聞系統做好之後我就非常鬱悶，我不知道我幹了一些什麼：

※     從資料實體到業務實體之間的轉換非常麻煩，而業務實體又不適合作為資料契約。業務實體的意義何在？

※     幾次轉換再加上WCF（基於HTTP），整個系統的效能奇差，WCF以及Linq先進的構架反而不如以前ADO.NET加上單物理伺服器的構架？

 

討論

 

    這位朋友的疑惑涉及到很多已經討論了很久的話題：

※     ORM的意義？

※     分布式（或者說面向服務）的意義？

※     領域模型的意義？

我認為：

※     很多時候，我們的思考都反了，不是說要OO才ORM，而是我們在建立了領域模型之後需要做持久化的工作，完善的ORM架構能幫我們做這個轉換、儲存的工作，減少了代碼量。

※     Linq To SQL主要還是針對資料庫模型（資料實體），並不能處理非常複雜的領域模型的持久化，可以關注ADOEF。

※     很多時候我們覺得一個概念沒有什麼意義，或者說帶來的反面效果比正面效果還大的時候往往是因為拿大炮打蚊子了。領域模型、SO、OO都是由於當前的理念滿足不了大型項目的要求而產生的，不是所有的項目都適合這些概念的。

※     有的時候看問題站在一個比較高的角度來看更客觀。比如從一個操作來看待效能問題不太客觀，應該從整個項目乃至整個系統（無數伺服器）的角度來看。

 

請大家討論…………

（由於大部分內容直接從MSN的對話中複製過來，所以比較亂，如果dudu覺得不合適馬上移走）

服務訊息、業務實體以及資料實體