What is the best approach to mapping between Entity, View Model or dataContract.

For example I've seen the following modelling structures for SOA.

WCF -> DataContract distributed to client.

Middle-tier -> Models and Interface with then mapped to repository type and eventual a concrete class which implements a ORM.

In some cases I've seen reflection used, others just setting the properties and third-party libraries like AutoMapper for C#.

What is the most effective way to keep your system "easy to maintain" and functional or horses for courses?

EDIT: Question wasn't focused on Microsoft, I've used SOA for java and the same problem happens regarding mapping. I'm asking about direct mapping vs. reflection and etc? Its really got nothing to do with ORMs.


    public interface IProduct { //bundle of properties and method signatures }

    public abstract class Product  implements IProduct { //implementation }

    public class Product extends Product implments IProduct { //implements and do stuff}

    public class Product extends Product implments IProduct { //implements and do stuff}

    public class ProductController 
      public IActionResponse Save(IProduct product)
          //save to sapMD repository
          IAction actionMd = ((thesolution.repositories.sapMD.Product)product).Save();

           //save to sapCRM repository
          IAction actionCrm = ((thesolution.repositories.sapMD.Product)product).Save();

          IActionResponse response = new thesolution.message.product.ActionResponse(); 
          return response;


      //XSD JAXB or etc.


//your service method

public class ProductServices ... {

  public thesolution.DataContracts.ResponseAction Save(thesolution.DataContracts.Product product){

    // so now how do you map back to IProduct manually, reflection or etc.


  • 2
    You might want to accept answers to your questions as a way to encourage folks to participate. – S.Lott Jul 14 '11 at 9:55

Personally I've had success with Domain Driven Design (DDD). DDD is not suitable for everyone.

However I suspect if you're using Service Oriented Architecture (SOA) then you may have suitably complex business logic to abstract away so that it can be changed independently of your architecture.

DDD and SOA have a kind of symbiosis. I don't have any direct resources to link, however Udi Dahan does training courses regarding using DDD & SOA.

Update: Heres a video of Udi Dahan giving a talk about using DDD with SOA.


Take the hint.

If it was easy, Microsoft would not have invented so many choices. If you Google "Entity Framework", you'll find even more (POCO EF4, etc.)

You can read articles like this: http://blogs.msdn.com/b/esql/archive/2007/12/14/entityframework_5f00_orm.aspx

Sadly, it's hard because -- possibly -- Microsoft has a lot of internal politics. All of their products need a place in the architecture, so there's a lot of mappings among all the various pieces and parts. It's hard for Microsoft to simplify anything. (Oracle may have the same kind of problem.)

If you step away from the Microsoft World View, however, it's still difficult, but it may not be quite so complex. Fewer products means fewer mappings.

Many folks use Object-Oriented databases (with no mappings) or very simple ORM tools (with very simple mappings in exactly one place.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.