集成到實體框架中的業務邏輯

我已經閱讀了關於BL的一些文章，但這種方法似乎對我來說並不直觀。它似乎打破了正常的OOP原則。這裏有一個非常簡單的例子：客戶表包含每個客戶的出生日期和性別。預期壽命表包含客戶ID，年齡以及該年齡段的生存概率。集成到實體框架中的業務邏輯

基本的OOP原則是不是要求將方法集成到實體中？例如。客戶端類中的calculateSPTable（）方法。

class client { 
    int clientId; 
    int age; 
    bool male; 
    list<surviveProb> lifeExpectancy; 
    void calculateLifeExpectancy(); // calculates lifeExpectancy 
} 
class surviveProb { 
    int surviveProbId; 
    int clientId; 
    int age; 
    double probability; 
}

然而，今天的方法似乎表明這些操作必須在一個單獨的層和一個單獨的類。在實體上操作的方法不應該包含在實體框架實體中。這似乎違反直覺。我真的想將方法放入EF實體中。這是否會導致問題？我在這裏錯過了什麼？

來源

2016-04-26 jlear

實體框架映射您的實體對象（例如屬性，方法，枚舉等）通過反射。現在考慮一下，一個實體有10個屬性，10個方法將其與另外一個具有10個屬性的實體進行比較，這將有更快的映射？ –

我想我理解屬性映射，但我不知道如何映射方法。 – jlear

經過一番研究，我現在使用了一些我認爲對維護海豚和理解應用有益的模式。假設你想註冊一個賬戶。在控制器中，我會有一個AddAccountViewModel，它只向用戶公開最小屬性。不用擔心他在意想不到的財產中注入不好的東西。現在，使用依賴注入，我會調用Facade。比方說，_accountsFacade.RegisterAccount和我將傳遞視圖模型作爲參數。在正面的這個方法中，我會做從視圖模型到模型的映射，這個Facade將負責完成所有需要完成的事情，以便創建帳戶。在我看來，這就是所有商業邏輯所在。在這個Facade中，再次使用依賴注入，我使用一個工作單元並添加和編輯實體到上下文中。 _unitOfWork.AccountRepository.Add（account）你看？控制器只是「路由」應用程序，門面處理業務，工作單元處理上下文，存儲庫只與數據庫通信...而模型只公開屬性。正如前面所述，這使映射更快，並且它分開關注。有時，添加帳戶的邏輯可能涉及處理不應在帳戶對象內使用的不同對象，因爲我的英語不太好，所以我希望你能理解我想解釋的內容。它對您有幫助嗎？

來源

2016-04-26 08:59:32

似乎DBContext是分隔問題的邊界，而不是實體。 DI發生在DBContext上。實體和業務邏輯不應隨DI改變。答案的關鍵似乎是映射方法會減慢速度，但我不明白什麼方法映射是如何減慢速度的。似乎應該通過映射來忽略這些方法。 – jlear

集成到實體框架中的業務邏輯

回答

相關問題