ASP.Net MVC - Is this entity layer a step too far?

I have a domain data model which returns a class such as the following:

public class ZombieDeath
{
    public virtual int ZombieId {get;set;}
    public virtual FatalHit {get;set;}
}

public class FatalHit
{
    public virtual int HitId {get;set;}
    public virtual string Zone {get;set;}
    public virtual string Weapon {get;set;}    
}

When passing this data back to my grids, I've read that is best to always return data to the views in a flattened format. So I have the following class that represents a grid row:

public class ZombieDeathRow
{
    public virtual int ZombieId {get;set;}
    public virtual int HitId {get;set;}
    public virtual string Zone {get;set;}
    public virtual string Weapon {get;set;}
}

So, when this is rendered, I just call Model.Weapon, instead of Model.FatalHit.Weapon. It does make the view's code much nicer to read开发者_运维技巧, but it's obviously an additional layer of work due to the mapping required.

Is this really a good way of working, or just a waste of time?

---

I think that there are merits to having a different design in the domain than in the presentation layer. So conceptually you are actually looking at two different models, one for the domain layer and one for the presentation layer. Each of the models is optimized for their purpose.

The domain layer is meant to provide a representation of the application domain independent of the user interface that you are using.

The model in the presentation layer can be different depending on what user interface technology you are using or what client is being used. For example the model in the presentation layer may look different for MVC than for WebForms (and some people are using both in parallel). The model in the presentation layer for a mobile device might look different than that for a browser running on a desktop. A web service may use yet another model to efficiently transmit data. If you use AJAX in your web application, you may prefer yet another model to efficiently transmit information, e.g. using JSON.

So, yes, generally I'd say that it is perfectly ok to have different models so long as they help you to implement your system in a way that makes it easy to understand and maintain. You mention that the view's code is "much nicer to read". In my opinion that's good enough as a reason!

---

A waste of time IMO. You'll spend too much time writing mapping code on anything but the most simple solutions.

Where did you read that it's best to flatten your ViewModel? A complex business object exposed as a property on the ViewModel might not promote entirely encapsulated code but in my experience with MVC projects a good domain model means this isn't going to be an issue except for the purists.

---

You are looking at a Relational Data structure, which is best to keep in the 3rd normal form. From this code I don't see why you need to separate FatalHit from ZombieDeath. Does it lose the 3rd normal form if you combine them in one class? Do other classes have FatalHit members?

If 2 separate classes are needed to represent this data, and the third, combined class is only used for working with ease in the view, I don't see the point in the third class.