2012-03-26 49 views
1

我在我的Web應用程序中訪問的DataAccess項目中有我的Fluent NHibernate設置代碼。使用流利NHibernate和ASP.NET MVC的DRY模型

作爲NHibernate配置的一部分,我定義了在映射到數據庫時要使用的模型。

public sealed class MyTypeMapping: ClassMap<MyType> 

這種模式MyType是相同的,我需要在我的web層傳遞到視圖的模型。我還想爲此模型添加一些額外的元數據,例如RequiredDisplayName

我確定這是一個常見的場景,其中數據訪問層中的模型與Web層中所需的模型相同。

這通常如何處理?在數據訪問層中使視圖依賴於模型還是我可以接受的做法,還是應該簡單地創建一個ViewModel以從視圖中提取細節?

我對ORM相當陌生,在MVC項目的模型文件夾之外放置我的模型並且重複模型感覺不正確感覺很奇怪。

你是如何處理這個問題的?

回答

2

它是一個公認的做法,使視圖依賴於模型的數據訪問層

在對於一些人來說,也許,沒有我。

或者我應該簡單地創建一個ViewModel來從視圖中提取細節?

這就是我會做的。

當然,如果你不想按照我的建議使用視圖模型,你有幾種可能性。因此,讓我們假設您有以下域模型:

public class MyDomainModel 
{ 
    public string Foo { get; set; } 
} 

但您想要將某些元數據與它關聯。

你有和第一種可能性是內置是使用[MetadataType]屬性:

[MetadataType(typeof(MyDomainModelMetadata))] 
public class MyDomainModel 
{ 
    public string Foo { get; set; } 
} 

,並有一個單獨的類中的元數據:

public class MyDomainModelMetadata 
{ 
    [Display(Name = "foo bar")] 
    public object Foo { get; set; } 
} 

但仍您的DAL必須知道不太好的元數據和表示邏輯。 MyDomainModelMetadata類必須在您的DAL中定義,因爲屬性表示編譯時烘焙到程序集中的元數據。

這給我們帶來包括編寫自定義模型元數據提供的第二種可能:

public class MyMetadataProvider : DataAnnotationsModelMetadataProvider 
{ 
    protected override ModelMetadata CreateMetadata(IEnumerable<Attribute> attributes, Type containerType, Func<object> modelAccessor, Type modelType, string propertyName) 
    { 
     // TODO: you could keep a static hashtable that will map between your 
     // domain model type and the associated metadata type in your UI layer 
     // but for the purpose of this demonstration I have hardcoded them to simplify 
     if (containerType == typeof(MyDomainModel)) 
     { 
      return GetMetadataForProperty(
       modelAccessor, 
       typeof(MyDomainModelMetadata), 
       propertyName 
      ); 
     } 
     return base.CreateMetadata(attributes, containerType, modelAccessor, modelType, propertyName); 
    } 
} 

將在您的Application_Start登記,將取代默認的元數據提供:

ModelMetadataProviders.Current = new MyMetadataProvider(); 

現在,您可以擺脫域模型中的MetadataType屬性,並在您的UI層(MVC應用程序本身)中擁有MyDomainModelMetadata類。

+0

感謝Darin的澄清。 – 2012-03-26 09:38:39

+0

非常感謝您的回答。非常有趣,非常感謝。 – 2012-03-27 07:01:21