Question

I have my Fluent NHibernate setup code in a DataAccess project which is accessed from my Web application.

As part of the NHibernate configuration I defined a Model to be used when mapping to the database.

public sealed class MyTypeMapping: ClassMap<MyType>

This model MyType is identical to a model that I require in my web layer to be passed to a view. I’d also like to add some additional meta data to this model such as Required and DisplayName.

I’m sure this is a common scenaro where models in the data access layer are the same as models required in the web layer.

How is this commonly handled? Is it an accepted practice to make a view dependent on a model in the data access layer or should I simply create a ViewModel to abstract the details away from the view?

I’m quite new to ORM and it feels odd to have my models outside of my Models folder in the MVC project and duplicating the model doesn’t feel right either.

How do you handle this?

Answer 1

Is it an accepted practice to make a view dependent on a model in the data access layer

For some people maybe, for me no.

or should I simply create a ViewModel to abstract the details away from the view?

That’s what I would do.

Of course if you don’t want to follow my suggestion of using view models you have a couple of possibilities. So let’s suppose that you have the following domain model:

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

but you wanted to associate some metadata to it.

The first possibility that you have and which is built-in is to use the [MetadataType] attribute:

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

and have a separate class for the metadata:

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

But still your DAL must know about metadata and presentation logic which is not quite good. The MyDomainModelMetadata class must be defined in your DAL because attributes represent metadata that is baked into the assembly at compile time.

Which brings us to the second possibility consisting of writing a custom model metadata provider:

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);
    }
}

which will be registered in your Application_Start and which will replace the default metadata provider:

ModelMetadataProviders.Current = new MyMetadataProvider();

Now you can get rid of the MetadataType attribute on your domain model and have the MyDomainModelMetadata class in your UI layer (the MVC application itself).