Re: Automapper in Service Layer - How and Where to create the mappings

[Ramon Smits]

On Mon, Oct 15, 2012 at 1:21 PM, Patrick Sardinha <patrick....@gmail.com> wrote:

Hi,

I need to create DTO's objects to move data from domain to viewmodels.

The problem is that in presentation layer i use global.asax to do the profile creation for all the mapping for the viewmodels, bu where and how I do the mapping in the service layer?

As in windows service? In your service start or program.cs

-- Ramon

[Dan Moffet]

I don't think this is the right approach.  A service layer should be unaware of your UI, and thus your view models.  If your service layer knows about your view models, then that means it's coupled to your view and thus your UI. 

 

The point of a service layer is that you should be able to re-use it with different kinds of front-ends.  Be it a web service, a desktop app, whatever.. You can't do that if the service layer is coupled to one specific UI.

 

I would suggest returning a domain (ie business, not data) object from the service layer and use AutoMapper in the UI to map it to a view model.

 

On Monday, October 15, 2012 6:21:36 AM UTC-5, Patrick Sardinha wrote:

Hi,

I need to create DTO's objects to move data from domain to viewmodels.

The problem is that in presentation layer i use global.asax to do the profile creation for all the mapping for the viewmodels, bu where and how I do the mapping in the service layer?

Thanks.

[Denis Lanza]

  I must disagree with you Dan. I am an Architect at a firm in NYC and we use AutoMapper in the service layer. Basically we have our domain model which are the classes with all of the business rules, properties and methods needed for the app. These classes are mapped via NHibernate to a SQL Server 2008R2 Db. We query NH in the repositories then return the actual domain objects to the service. The service method then converts the objects to DTOs and sends them back across the wire to the calling client. Mind you these are RESTful Services. Also we use a service agent that calls the service thus the developer is never programming against the service directly avoiding tight coupling. DTOs are necessary as they are lightweight, flattened versions of the domain objects just containing the data. WCF knows how to serialize them using the DataContractSerializer so that is taken care of for you.

  As far as tying it to the UI, that is not accurate. We use the same DTOs for ASP.NET apps, MVC 3/4 apps, iPad apps, mobile apps. All of these platforms still consume the data of the objects of the app domain.

 

Sincerely,

Denis J. Lanza

Technical Architect

Dealogic NYC

--
You received this message because you are subscribed to the Google Groups "AutoMapper-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/automapper-users/-/lICNXtcBwgEJ.
To post to this group, send email to automapp...@googlegroups.com.
To unsubscribe from this group, send email to automapper-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/automapper-users?hl=en.

[Dan Moffet]

I'm sorry Denis, what exactly are you disagreeing with?  I suggest you re-read my message.

 

The original post was talking about returning View Models from the business layer.  He wanted to map his DTO's to his view models in the business layer.

 

My comment was that I don't think this is good design, because it makes the business layer coupled to the UI's Views (not the other way around). 

 

What you are describing is normal behavior, but was not what I was talking about.

[Denis Lanza]

  Ok. I was more so replying to his original question which was:

I need to create DTO's objects to move data from domain to viewmodels.

The problem is that in presentation layer i use global.asax to do the profile creation for all the mapping for the viewmodels, bu where and how I do the mapping in the service layer?

It sounds there like he is asking how to create the actual DTOs that will shuttle the data across the wire supplying the data that will be used in the ViewModels. Yea from domain to viewmodel not creating the viewmodels in the service layer. I suppose I could be misreading it though.

 

Denis

To view this discussion on the web visit https://groups.google.com/d/msg/automapper-users/-/8f1OVVr2hYwJ.

[Patrick Sardinha]

Thanks for your response, but how can I build the profiles if I can only have 1 Initialize in the project? I can't Initialize the mapping for the presentation layer and for the service layer

       public static void Configure()

        {

            Mapper.Initialize(x =>

            {

                x.AddProfile<DomainToDtoMappingProfile>();

                x.AddProfile<DtoToDomainMappingProfile>();

            });

        }

       public static void Configure()

        {

            Mapper.Initialize(x =>

            {

                x.AddProfile<DtoToViewModelMappingProfile>();

                x.AddProfile<ViewModelToDtoMappingProfile>();

            });

[Dan Moffet]

I don't really follow you, Patrick.

 

What does initialization have to do with the problem you were asking about? 

 

My response to you was that you should not be returning View models from your service layer, because that would require the service layer to be dependent upon the UI.  This has nothing to do with initialization, and everything to do with how you have structured your layers and dependencies.

[Patrick Sardinha]

Hi,

The problem here is that, to keep the layers independent, the UI should not be responsable to initialize the automapper profiles do build the mappings, but as you know, there can only have one initialization of the profiles per project, so you have to do it in only one place, the Global.asax, correct?

I tried to initialize in the service and in the UI but automapper don't allow that, so I had to put the initializstion in the Global.asax that makes the service mappings dependent of the Ui and I would prefer to keep them independent for example to another Ui in the futures.

So, regarding this, how would do the initialization of the mapping in the service layer without doing any call from the global.asax in the UI?

Regards.

--

You received this message because you are subscribed to the Google Groups "AutoMapper-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/automapper-users/-/ojeofgADI6gJ.

[Ramon Smits]

Having independant layers does not mean that you cannot use the same mapping infrastructure. Your example is using the static global version of AutoMapper so you share the same instance accross different 'layers'. Either share one instance (the static methods) or create your own automapper instance so you use the automapper interfaces. Your 'configure' methods should be put in the application host that bootstraps your application.

What I use very successfully is that I scan the assemblies for configurations and pass these to the Initialize method. If I add a configuration I do not have to alter the initialization code as it will automatically be loaded.

-- Ramon

[Ramon Smits]

Anothor option is to put the mapping creation in a static constructor of the class where you call the mapping. I really liked that approach as usually the mapping  is tightly coupled to where the mapping is called but it is not really testable.

-- Ramon

[Patrick Sardinha]

Hi,

Can you share an example of how to do that?

Tks.

No dia Domingo, 21 de Outubro de 2012, Ramon Smitsram...@gmail.com escreveu:

Anothor option is to put the mapping creation in a static constructor of the class where you call the mapping. I really liked that approach as usually the mapping  is tightly coupled to where the mapping is called but it is not really testable.

-- Ramon

--

You received this message because you are subscribed to the Google Groups "AutoMapper-users" group.

[Denis Lanza]

  Your service and UI should be in completely separate projects. Compile the service then put the DLL in your UI project if it's REST. If it's SOAP, add a service ref. You want to keep your layers as loosely coupled as possible. We put the interfaces in a separate project from the implementation. This way the client (service agent) only knows about and utilizes the interfaces. This way you can use DI. Use AutoMapper in your service layer to convert domain objects to DTOs then use it in your UI layer to convert DTOs to ViewModels. I believe that would work.

 

Denis

 

--

You received this message because you are subscribed to the Google Groups "AutoMapper-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/automapper-users/-/gkyOCwUBc30J.

[Patrick Sardinha]

Ok, thank you very much.

2012/10/22 Denis Lanza <denis...@gmail.com>

[Ben]

+1

 

Enjoyed reading this thread.  Would read again.

 

Ben

[Ben Joyce]

I tend to agree with the architecture described below.  I've had developers work for me in the past where they thought it was ok to use DTOs in the presentation layer, no no no... even if the structure and content of the class is the same I'd still prefer that the DTO is mapped to a ViewModel and exposed that way.

 It's more work/code/time but feels the right thing to do.

Ben

On Tuesday, January 22, 2013, wrote:

If I may add: DTO's are not view models. DDD and system architecture does not employ convention over configuration. So, in short, why expose domain entities in the instance when a ViewModel needs to be constructed? What if the domain entity contains security details the view (or developers on the UI layer) should never have access to?

Maintaining a proper architecture with boundaries across layers imposes no risk since the possibility doesn't exist. My opinion, keep Automapper in the service layer, and in the UI layer;

 DTO to ViewModel mapping in UI layer <-> DTO to Entity mapping in service layer <-> Service layer <-> Data Access Layer 

--
 
 

[Patrick Sardinha]

Hi, I could not agree more with you.

With this approach you can filter what information to pass trough the "comunication channel" cold DTO's to the Domain, and only send what it's really necessary to insert in the database.

Regards,

Patrick.

2013/1/24 Ben Joyce <ben....@gmail.com>

--