Best Practice/Pattern to Populate 'ViewModel' objects

Folks,

I'm trying to figure out a pattern or best practice to translate data from the domain o开发者_高级运维bjects/data source over to the 'ViewModel' object. In my particular example, the domain object is the WCF proxy objects. Any call to the WCF methods will populate these proxy objects which finally gets transferred over to the 'ViewModel' objects. See Architectural diagram

This microsoft article: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx talks about using a Repository pattern. It's mentioned under 'The Data Model and Repository' section. Is that the best approach? Can someone advice me?

dorman

---

Repository pattern is related to data access layer (what is inside your WCF). This has nothing to do with presentation layer.

I would suggest you declare your Model and ViewModel classes in MVC project based on the requirements for the UI (without taking your database schema into consideration). You can then use AutoMapper to simplify the code needed to copy values from WCF proxy classes to your Models. You might want to encapsulate this code in an Adapter class that will shield the rest of app from AutoMapper code.

EDIT:

Do not use your WCF proxies as model classes. Declare separate model classes based on your UI and use AutoMapper to copy data between them.

---

Yes, you need to have a repository. That will give you some advantages, like easy testing of the view model; also an easy switching to another kind of repository later.

In terms of the article you provided, - it gave them an advantage of unit-testing the view-model logic; and, later on, they can switch from XML files repository to the SQL server repository (as an example).

Just make sure to have abstract repository injected into ViewModel.

---

Keep it simple, and have a single responsibility per class.

This suggests some separation between the objects returned by your proxy (Communication Objects) and the ones used by your ViewModel (View Objects). This way the client-side logic is decoupled from the communication/transmission method.

If you have WCF service closely related to UI elements, then simply translate from CO to VO. Since the view is bound to VOs, then view gets updated.

If you need to insert business or domain logic on the client, translate to an intermediary domain object. Then have the object interact with the other domain model objects (the so-called repository in the article you mention). VO should listen to domain changes and react accordingly. This pattern suggests the domain objects have no dependency on WCF nor WPF.