This project has moved. For the latest updates, please go here.

ViewModel from more than one models

Jun 16, 2010 at 10:59 AM
When I need to display data coming from various objects, I create a ViewModel containing properties from more than one model. For ex. I have the following objects, Customer and Store. In my viewmodel i want to have Store.Location and Customer.Name. How can I map a viewmodel to properties of two (or many) types? Thanks in advance.
Jun 16, 2010 at 2:05 PM
Edited Jun 16, 2010 at 8:24 PM

You can define a ViewModel class that does not map to a Model class. See the examples and look at the Persons class. It contains a property Collection (type Persons (ViewModel)). You can easily add more properties of other ViewModel types.

Each of the other two classes (Customer and Store) will have their own mapping file. And the third (Order(?)) will have one too but no mapping to a Model class.

Does that answer your question?

Jun 16, 2010 at 9:59 PM

I have spent more time thinking on this. Indeed, when the ViewModel class has two properties StoreLocation and CustomerName and you want to map them from two Model classes and their properties you have 'a problem' as this is (not yet) supported if the two types (customer and store) are not wrapped in a single object.

I'll do some designing on this and I will make some tests. I am thinking about changing the single ModelClass attribute in the mapping file to an element ModelClasses.

The MapTo and MapFrom methods will then have (possibly) multiple parameters (all Model classes) depending on extra information that is added to each property specifying what ModelClass it maps to. this can easily become quite messy so it will take me some time to get it clean, obvious and still easy to use.

Thoughts are very welcome. Thanks for your review!

Jun 17, 2010 at 5:03 AM
Edited Jun 17, 2010 at 5:04 AM

There is another way someone could do this, so you would not have to add support for it. One could expose this through DTOs so at the end you would not have to change the way this (great) library works. At then end, flattening is something most people do when exposing the underlying model through DTOs. I think I could use the library this way.

Anyway, I love the whole concept with this Mapper library and all wpf disciples will agree with me! This is even more loosely coupled way of doing MVVM.

Best Regards,

Nikos Baxevanis

P.S.: Do you think of adding Fluent Interface support?

Jun 17, 2010 at 6:01 AM

Yes, the flattening could be done in the DTOs.

To be honest: I prefer my web service calls to have a single parameter, always. So I always have a single object that I need to map to the ViewModel.  So that is why I built the first release of the mapper this way. You can see it in my assumption that the providers (both Model and ViewModel provider) also have a single parameter. And as (asynchronous) method only returns a single object it is more natural to always consider single input/output. It's a more message based approach.

What would you consider an appropriate place in the generated code for Fluent Interface support? I am not quite sure where the generated code would benefit from that.


Jun 17, 2010 at 10:08 AM
Edited Jun 17, 2010 at 10:10 AM

I am inspired by NHibernate's mapping files and Fluent NHibernate's fluent mapping and I combined it so one may map ViewModels to DTOs or any referenced object (code generated, etc.) fluently. Just thinking..!

Jun 17, 2010 at 10:35 AM

Ah, I understand. I don't think there is much to gain because the Mapper only generates the ViewModel and the ViewModel Provider. Not the Model. That is why I chose to generate the Mapping methods on the ViewModel classes. To have a Fluent Interface I would need to modify the Model as well.

Besides, the mapping functions are only called in generated code and the developer should really stay away from them.

A feature I am considering is building a DSL for Visual Studio to model the mapping file instead of typing it. But at this time the mapping file is so very basic that I can't imagine a lot of reasons why we'd need a graphical tool to make the mapping file other than easier adding WrappedMethods.