2009-07-13 49 views
0

好的,標題不是說太多,對不起。從本質上講,它是一個關於可以有多個數據庫後端的應用程序的體系結構問題(嗯,這裏鬆散地使用了「數據庫」,因爲它可以表示任何從MSSQL到XML文件到內存中的IList),本質上涉及存儲庫模式。具有多個後端/ DI架構時的ORM和POCO? AutoMapper?

我有一組POCO,基本上只是用作數據傳輸對象(DTO),因此除了攜帶數據外什麼都不做。不幸的是,我看到自己需要用屬性來修飾它們,即用於特定的ORM或甚至用於XmlSerializer。這意味着他們現在有點受數據庫層的約束,在我看來不再是簡單的POCO了。

從我看到的,我現在必須複製這些DTO類,以便我有一個特定於數據庫的類與屬性和任何我需要的,第二個版本是通過我的應用程序通用。我的模型然後將不得不轉換它們(這就是可以使用類似於AutoMapper的東西)

它只是仍然「感覺很奇怪」,因爲我基本上覆制了所有的DTO類,但是存在Object-to-Object映射器似乎表明這很好。此外,這似乎複製ADO.net方法,而有一個通用部分(向DataSet)和數據庫特定部分。

這是正確的嗎?還是有不同的方法?

回答

1

只有的情況下(需要添加用於給定ORM的屬性),可以編寫一個在運行時添加這些東西的包裝器。您可以將這些代碼添加到ORM構造函數(根據需要對ORM或ORM初始化類進行子類化),或者添加到ORM初始化事件。

一個例子在下面給出用於使用反射屬性標記三個屬性,但它可以被容易地修改將屬性添加到一個類型,或所有的特性等從here改編

PropertyDescriptor[] properties = TypeDescriptor.GetProperties(this); 
//Add as necessary 
string[] propertiesToTagForORM = { "Name", "Category", "Description" }; 

foreach (string propname in propertiesToTagForORM) 
     { 
      PropertyDescriptor prop = properties[propname]; 
      if (prop != null) 
      { 
       AttributeCollection runtimeAttributes = prop.Attributes; 
       // make a copy of the original attributes 
       // but make room for one extra attribute 
       Attribute[] attrs = new Attribute[runtimeAttributes.Count + 1]; 
       runtimeAttributes.CopyTo(attrs, 0); 
       attrs[runtimeAttributes.Count] = new BrowsableAttribute(false); 

       prop = TypeDescriptor.CreateProperty(this.GetType(), propname, prop.PropertyType, attrs); 
       properties[propname] = prop; 
      } 
     } 
} 

。只是一個想法 - 這可能是我頭的第一個方向:)

+0

這是一個有趣的想法。基本上我可以將我的後端作爲單獨的程序集並讓它們根據需要操作POCO ...我一定會記住這種方法。 – 2009-07-13 17:31:23

+0

確實。如果您嘗試它,那麼獲得有關如何爲您解決問題的反饋會很有用。如果是的話,請在這裏發帖 – JoshJordan 2009-07-13 17:45:46

0

你應該問自己,當你在POCO中包含這些屬性時會出現什麼問題。特別是如果你的POCO只做數據並且不作爲一個帶有業務邏輯的領域模型,你希望在屬性中保留單獨的「技術細節」。在這種情況下,這些屬性的唯一缺點似乎是較低層次的技術細節漏入較高層次。但是,這是否證明了一個全新的層面,在這個層面上你只會做「愚蠢的屬性複製」。我可能會說不。

簡而言之:總是仔細考慮是否解決感知問題並不會導致其他問題(甚至可能更大)。我自己不會過多擔心你說明的情況。如果有的話,我寧願尋找選項來保持POCO的屬性,並將它們放在其他資源(類或配置文件)中,而不是引入額外的轉換層。