基礎類和實體框架的用戶定義轉換

在3層項目中使用entity framework (EF)作爲ORM工具，我發現實體框架生成的代碼爲DAL + BLL。由於DAL和BLL在這種情況下是不同的層次，並且不同的編碼器可以在它們中的每一個上工作，所以需要將每個層分離爲不同的項目。基礎類和實體框架的用戶定義轉換

的問題是，我不想改變EF生成的代碼，仍然需要BLL一個額外的項目（我所知道的EF部分類和On...Changing() methods，但這並不能使概念的良好分離的意義，我也不能在不同的項目中實現部分類）。

我希望EF會爲每個實體生成一個接口，然後將其作爲生成的代碼實現。這樣，我可以通過我的BLL類來實現這些接口。然後對EF設計器中的實體進行更改將導致自動更改接口，並且我的BLL將停止工作（由於接口已更改，不再編譯）。不幸的是，EF不提供這些接口，並且從生成的代碼中提取它們很難維護，因爲任何對模型的新更改都需要手動再次提取它們。

後來我想包裝實體框架生成的類與我們自己的BLL類（從EF類派生BLL類），並增加額外的BLL邏輯有（驗證，業務規則等）和隱藏與BLL當量基本方法和屬性。

// example of a new property which facilitates using an EF object 

class EFaccount // EF generated class 
{ 
    DateTime CreationDate { get; set; } 
    DateTime ExpiranDate { get; set; } 
} 

class BLLaccount : EFaccount // BLL class 
{ 
    new DateTime CreationDate { get; set; } 
    new DateTime ExpiranDate { get; set; } 
    // Total age in days as a new property. Storing this, in dbase cause unnecessary redundancy 
    int Days { get { return (ExpirationDate - CreationDate).TotalDays; } } 
}

由於BLL類是從它們的等效EF類派生的，我需要從和向這是不允許的基類鑄造。

在我的情況下，如果我從EF轉換爲BLL這意味着對象來自dbase，額外的屬性可以很容易地從基類中計算出來，但是編譯器不允許從基類轉換。如果我從BLL投射到EF這意味着對象將被存儲在dbase中，所以額外的屬性可能會被丟棄，但編譯器不允許投射。

你有什麼建議？

來源

2011-02-18 Xaqron

爲什麼不直接跳過代碼並使用POCO的呢？ – RPM1984 2011-02-18 05:34:39

的建議是：

使用實體框架4
使用實體對象或最好POCO
使用實體對象或POCO T4模板
修改T4模板添加額外的功能，爲你 - 應該可以生成和實現基於實體屬性的接口。

你不想額外編碼的論點是荒謬的。你已經證明，使用生成的代碼，你需要很多額外的編碼，並且你有很多額外的複雜性。生成並不意味着好。如果您無法修改代碼，那麼使用生成的代碼並不容易（只有在編寫自己的代碼生成自定義工具時纔可能這樣做）。所以這裏是T4模板的明顯優勢。

來源

2011-02-18 11:29:22

基礎類和實體框架的用戶定義轉換

回答

相關問題