Question

I am using FluentNHibernate with AutoMapping and conventions to create my database. I have 3 tables - Person, Address and Job as shown below.

    //Database table
  public class Person()
  {
    public virtual int Id { get; set; }
    public virtual string FirestName { get; set; }
    public virtual string SecondName { get; set; }

    public virtual PersonAddress Address { get; set; }
    public virtual PersonJob Job { get; set; }
  }

  //Database table
  public class PersonAddress()
  {
    public virtual int Id { get; set; }
    public virtual string AddressLine1 { get; set; }
    public virtual string AddressLine2 { get; set; }
    public virtual string AddressLine3 { get; set; }
  }

  //Database table
  public class PersonJob()
  {
    public virtual int Id { get; set; }
    public virtual int Description { get; set; }
  }

I want to display a list of Person details in a Grid using a flattened view model below. Do I have to create a Mapping for ViewModelPerson even though its not a database table (will Automapping affect this) or should I do this using a nHibernate query to create get the list of ViewModelPerson entities.

  //NOT database table - only used as ViewModel
  public class ViewModelPerson()
  {
    public virtual int PersonId { get; set; }
    public virtual string FirestName { get; set; }
    public virtual string SecondName { get; set; }

    //AddressLine1 + AddressLine2 + AddressLine3
    public virtual int AddressId { get; set; }
    public virtual string Address { get; set; }

    public virtual int JobId { get; set; }
    public virtual string Job { get; set; }
  }
Was it helpful?

Solution

Let me give you my view, the approach I do believe in...

Data Layer - The mapping Entity vs Table is a Data layer related. It is just a way, how to later profit from ORM tool like NHibernate. All the CRUD operations are generated for us - reflecting the mapping.

Presentation Layer - The ViewModel, should help us to "map" the Entity(-ies) to Client View. So while in many simple scenarios will: Entity, Table, ViewModel .. (e.g. Country or Currency) match 1-1, we are ready to handle it differently in more complex scenarios.

The above scenario Displaying Person, Address, Jobs at one View - is a complex one. Can we profit from separation, indirect filling of the ViewModel?

Suggestion: Fill the ViewModel on a Service layer using queries to underlying Business model

The first benefit I see, is that the population of the ViewModelPerson is in our hands. It is not fixed inside of the mapping. We can reduce amount of data (even use Projections to load less data) and we can even extend it (load City from some CodeList)

The second benefit is that if we will need to change something, e.g. introduce async loading of the Addresses, we have to change it only from the Service layer UP (in MVC Controller, Model and View) while the data layer (mapping is untouched)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top