服務訊息、業務實體以及資料實體
名次解釋
服務訊息 － 分布式應用中各個服務之間傳遞的訊息，以wcf為例的話就是資料契約。
業務實體 － 業務物件模型、領域模型中和業務相關的實體。
資料實體 － 完全和關係型資料庫結構對應的資料實體。
問題
今天有人在msn上問了我乙個問題引發了我的思考，問題大致如下：
最近在學習3.0的一些技術，比如wcf和linq，我嘗試使用這些技術寫乙個分布式的新聞系統，系統的構架如下：
※乙個資料訪問層，其中包含了乙個資料實體（自動生成的）。資料訪問層使用linq to sql進行資料訪問操作，並且把資料從資料實體轉化為領域模型中的業務實體。
※乙個業務邏輯層，以領域模型為核心。業務邏輯層使用linq to object再把業務實體轉化為wcf的資料契約。
這樣，整個專案中就有了三個實體：※※
※等新聞系統做好之後我就非常鬱悶，我不知道我幹了一些什麼：
※從資料實體到業務實體之間的轉換非常麻煩，而業務實體又不適合作為資料契約。業務實體的意義何在？
※幾次轉換再加上wcf（基於http），整個系統的效能奇差，wcf以及linq先進的構架反而不如以前ado.net加上單物理伺服器的構架？
討論
這位朋友的疑惑涉及到很多已經討論了很久的話題：
※orm
的意義？
※分布式（或者說面向服務）的意義？
※領域模型的意義？
我認為：
※很多時候，我們的思考都反了，不是說要oo才orm，而是我們在建立了領域模型之後需要做持久化的工作，完善的orm框架能幫我們做這個轉換、儲存的工作，減少了**量。
※linq to sql
主要還是針對資料庫模型（資料實體），並不能處理非常複雜的領域模型的持久化，可以關注adoef。
※很多時候我們覺得乙個概念沒有什麼意義，或者說帶來的反面效果比正面效果還大的時候往往是因為拿大炮打蚊子了。領域模型、so、oo都是由於當前的理念滿足不了大型專案的要求而產生的，不是所有的專案都適合這些概念的。
※有的時候看問題站在乙個比較高的角度來看更客觀。比如從乙個操作來看待效能問題不太客觀，應該從整個專案乃至整個系統（無數伺服器）的角度來看。
請大家討論…………
（由於大部分內容直接從msn的對話中複製過來，所以比較亂，如果dudu覺得不合適馬上移走）
業務實體和庫存組織
有區分不清org id和organization id,其實org id來自表hr operating units，指ou 業務實體 的id。organization id來自表org organization definitions 是庫存組織id。業務實體表 查出業務實體 select from...
UML 核心元素之業務實體
如果說參與者和用例描述了我們在這個問題領域中達到什麼樣的目標，那麼業務實體就描述了我們使用什麼來達到業務目標以及通過什麼來記錄這個業務目標。如果把問題領域比喻成一幢大樓的話，業務實體就是構成這幢大樓的磚瓦和石頭。業務實體包含屬性和方法 屬性是用來儲存業務實體特徵的乙個記錄。乙個事物通常有非常多的屬性...
業務資料實體（model） 需要轉殖的方法
業務資料實體 model 需要轉殖的時候 可以使用 json.deserialize json.serialize inqresult json序列化再反序列化 方法二 例如實體名稱 inquireresult 實體中包含實體 cfettrade 實體 實現icloneable 介面，實體中新增方法...