實體框架和業務層/邏輯

Question

我試圖建立一個產品/收據像應用程序的一個MVVM輕 - EF應用程序的體系結構的一些自學 。 我有一個產品和收據表/實體在多對多關係的Db/EF。 然後我有一個DAL，只需使用Linq來做簡單的CRUD。

問題是在哪裏以及如何將我的業務邏輯放在這個應用程序中。

一對夫婦的想法浮現在腦海

選項1 -make一個ReceiptBo（回執業務對象） 至極繼承實體收據類的ICollection（ProductBo） 的ReceiptBo類將負責添加產品，計算總計和小計，並調用Dal插入。 maby這個選項似乎有點矯枉過正。

選項2 通過使用部分類 和簡單地使用BuisnessLayer調用達爾在生成的Entity對象計算方法-put。 這將使Buisnesslayer類在我看來過時，我不知道實體類應該用於業務邏輯嗎？

選項3 -make的業務類，但不要打擾使用繼承，只是將產品添加到實體的和做的計算存在，並調用達爾的插入。 這似乎很簡單，但不是很優雅。

選項4 的-none以上和IM無能

現在即時通訊不使用WCF，但想法是，我想使這個應用程序鬆耦合，這樣會很容易實現它，進一步擴展它。

也有點困惑什麼業務層。在一些例子中，它更像是用於計算的Dal，後來有人說這沒有完成。

有些幫助會很大。THX

PS：抱歉，我的英語不好

Answer 1

真的，我會去這裏簡單的選擇一個共同的多層體系結構設計如下：

• 數據訪問層（基本上，你的實體框架模型以及所有實體）
• 一個公開訪問實體的方法的業務層（CRUD方法+運行某些邏輯的任何自定義方法）
• 通過WCF公開無狀態方法的服務層（servi CE +使用MVVM圖案數據合同）
• 表示層（你的情況）
  • 視圖（XAML頁）
  • 的ViewModels（C＃類）
  • 模型是由通過露出的實體這裏表示業務層

我不會在實體直接添加任何方法WCF。所有方法都在業務層中定義，並由服務層公開。

Answer 2

通常我將我的業務邏輯保存在我的ViewModels而不是我的Models中，我將EF對象視爲Models。他們至多會進行一些基本的數據驗證，例如驗證長度或必填字段。

例如，EditRecieptViewModel將驗證業務規則，例如驗證值是否在特定範圍內，或驗證用戶是否有權編輯該對象，或在值更改時執行一些自定義計算。

另外，不要忘記，ViewModels應該反映視圖，而不是一個Model，因此不是每個Model都會有自己的

的 ViewModel