Click here to Skip to main content
15,312,747 members
Articles / Desktop Programming / WPF
Posted 7 Sep 2009


69 bookmarked

From Russia with Love – Retrieving ViewModel Objects from a Model Assembly

Rate me:
Please Sign up or sign in to vote.
4.98/5 (31 votes)
7 Sep 2009CPOL6 min read
Reviews the “From Russia with Love” technique of simplifying the creation of ViewModel objects from other libraries, without compromising your MVVM architecture


This article examines a way to easily transform data model objects into ViewModel objects, and safely add them to an observable collection, without introducing awkward assembly dependencies into an application. The technique makes use of generic delegates and the SynchronizationContext to maintain loose coupling between assemblies. This approach to transforming data types is applicable outside the realm of WPF and the Model-View-ViewModel (MVVM) pattern, but the article focuses on its use within a WPF application built using MVVM.

I nicknamed this technique “From Russia with Love” because it allows you to conveniently receive UI-friendly objects from a foreign, distant place in your application.


This article assumes that the reader is familiar with building WPF applications based on the Model-View-ViewModel design pattern. The demo application, which is available for download at the top of this article, makes use of the ObservableObject and RelayCommand classes from my MVVM Foundation library on CodePlex. The MVVM Foundation DLL is included in the demo project.

The problem

When building an application structured according to the MVVM design pattern, it is often useful and necessary to have the Model and ViewModel types live in different assemblies. The classes that retrieve data objects (i.e. Model objects) often live in an assembly that has no knowledge of or access to the application’s ViewModel types. The ViewModel classes have intimate knowledge of the Model classes, and usually issue requests to classes that retrieve and instantiate Model data. Thus, the assemblies in which ViewModel classes reside reference the assemblies in which Model classes reside, but not vice versa.

This configuration is a natural and expected side-effect of the MVVM design pattern, wherein the Model classes represent the “pure” domain of the system being developed, and the ViewModel is an adapter between a user interface (UI) and the data model. A consequence of this setup is that the ViewModel classes are often burdened with the task of creating ViewModel objects that contain one or more Model objects. The logic that performs this task can easily lead to code bloat in the ViewModel classes, and can give them too much “code gravity” – which means that more and more code will end up being added to the ViewModel classes as time goes on.

A preferable solution would spread out the task of transforming Model objects into ViewModel objects across the parties involved, such that each party would contain reusable code responsible for the work most appropriate to it. Of course, using the term “most appropriate” indicates that this decision is open to interpretation. For the remainder of this article, I will examine a design that satisfies my opinion of how to best solve this problem. If your application’s needs are not met by the choices presented herein, you are free to abandon my approach and adopt that which best suits your specific needs.

Before moving forward, let’s first review the problem in more detail. What follows is a list of requirements that must be met by the solution:

  • The ViewModel should be able to issue a request for a set of Model objects, provide some logic that transforms a Model object to a ViewModel object, and never be bothered to perform any subsequent processing.
  • The ViewModel objects that are created should be added to an ObservableCollection<T> where T is the type of ViewModel being created.
  • The observable collection must be populated on the UI thread, as per the constraints imposed by WPF’s binding system.
  • The ViewModel object that issued the data retrieval request should be notified once all data objects have been retrieved and transformed into ViewModel objects and added to the observable collection. This gives it the opportunity to update the UI to indicate that the data loading process is complete.
  • The assembly that contains the Model types and transforms them into ViewModel objects cannot have a reference to the assembly containing the ViewModel types.

An Example of the Problem

Suppose the Model assembly contains a Person class:

/// <summary>
/// Model class that represents a person.
/// </summary>
public class Person
    public Person(string firstName, string lastName)
        this.FirstName = firstName;
        this.LastName = lastName;
    public string FirstName { get; private set; }
    public string LastName { get; private set; }

Now imagine that the UI needs to display Person objects in a list, where a button represents each person, and clicking a button causes the application to “select” that person (what selection means in this context is irrelevant to the discussion).


Each button in the UI executes a command referenced by its Command property upon being clicked. This means that each Person data object needs to somehow be associated with a command object, so that when a button is clicked its command knows which person was selected. To satisfy that requirement of this application, let’s create a CommandViewModel class:

public class CommandViewModel
    public CommandViewModel(ICommand command, string displayName, object commandParameter)
        this.Command = command;
        this.DisplayName = displayName;
        this.CommandParameter = commandParameter;
    public ICommand Command { get; private set; }
    public object CommandParameter { get; private set; }
    public string DisplayName { get; private set; }

All of the CommandViewModels are stored by one CommunityViewModel object (a class that represents a community of people), inside of its MemberCommands collection.

/// <summary>
/// Returns a read-only collection of command objects, each of which represents a 
/// member of the community.  When a command executes, it 'selects' the associated member.
/// </summary>
public ReadOnlyObservableCollection<CommandViewModel> MemberCommands{ get; private set; }

Now let’s see how the UI displays a collection of these CommandViewModel objects:

<ItemsControl ItemsSource="{Binding}">
        <CollectionViewSource Source="{Binding Path=MemberCommands}">
                <scm:SortDescription PropertyName="DisplayName" />
                Command="{Binding Command}"
                CommandParameter="{Binding CommandParameter}"
                Content="{Binding DisplayName}"

At this point we know about the data model (the Person class) and the View and ViewModel (an ItemsControl that displays each CommandViewModel in the MemberCommands property of a CommunityViewModel). Now we need to determine how these two pieces of the application are tied together. The CommunityViewModel class needs to somehow retrieve the Person objects and populate its MemberCommands collection with CommandViewModels that represent each Person.

The Solution

A method in the Model assembly that retrieves Person data can be passed a delegate that takes a Person parameter, and returns a CommandViewModel object. However, since the Model assembly cannot have a reference to the ViewModel assembly, one might expect this to lead to a compiler error because the Model assembly cannot reference ViewModel types. This problem can be solved via the use of generic delegates. Since the return type of the delegate can be left unspecified as a generic type parameter, the Model assembly can successfully compile even though it is being used to create ViewModel types of which it has no knowledge.

Here is PersonDataSource, from the Model assembly, which is used to perform this task:

public class PersonDataSource
    public void RetrieveAndTransformAsync<TOutput>(
        ObservableCollection<TOutput>   output, 
        Func<Person, TOutput>           transform, 
        Action                          onCompleted)
        if (output == null)
            throw new ArgumentNullException("output");
        if (transform == null)
            throw new ArgumentNullException("transform");

        // One possible improvement would be to create an overload of this method that
        // has a SynchronizationContext parameter, so it can be invoked on any thread.
        var syncContext = SynchronizationContext.Current;
        if (syncContext == null)
            throw new InvalidOperationException("...");

                // Fetch the data objects.
                var payload = RetrievePeople();

                // Transform each data object and add it to the output collection, 
                // on the UI thread.
                if (payload != null)
                      arg => CreateOutput(payload, output, transform, onCompleted), null);
                // Implement error processing here...

    static void CreateOutput<TPayload, TOutput>(
        IEnumerable<TPayload>           payload,
        ObservableCollection<TOutput>   output,
        Func<TPayload, TOutput>         transform,
        Action                          onCompleted)
        foreach (TPayload dataItem in payload)
            TOutput outputItem = transform(dataItem);

        if (onCompleted != null)

    static Person[] RetrievePeople()
        // Simulate network latency for the demo app...

        // In a real app this would call an external data service.
        // The data access call would not have to be async, because
        // this method is executed on a worker thread.
        return new Person[]
            new Person("Franklin", "Argominion"),
            new Person("Douglas", "Mintagissimo"),
            new Person("Mertha", "Laarensorp"),
            new Person("Zenith", "Binklefoot"),
            new Person("Tommy", "Frankenfield"),

The PersonDataSource class provides support for both data retrieval and transformation. The logic for transforming each Person into a ViewModel object is given to it via the transform delegate, which is a parameter of the RetrieveAndTransformAsync method. Notice that it uses the current SynchronizationContext to marshal back to the UI thread, instead of using WPF’s Dispatcher, in case this code must be eventually used to support other UI platforms. I intentionally omitted any error handling logic, because that kind of code can vary a lot across different applications.

Now it’s time to see how the CommunityViewModel, back in the main EXE assembly, uses the PersonDataSource class.

public CommunityViewModel()
    _memberCommandsInternal = new ObservableCollection<CommandViewModel>();
    this.MemberCommands = 
       new ReadOnlyObservableCollection<CommandViewModel>(_memberCommandsInternal);

    // Create the command that is used by each CommandViewModel in MemberCommands.
    _selectMemberCommand = new RelayCommand<Person>(this.SelectMember);

    // Create the data source and begin a call to fetch and transform Person objects.
    var dataSource = new PersonDataSource();
        _memberCommandsInternal,         // output
        this.CreateCommandForPerson,     // transform
        () => this.IsLoadingData = false // onCompleted

    this.IsLoadingData = true;

void SelectMember(Person person)
    // In a real app this method would do something with the selected Person.
    string msg = String.Format("You selected '{0}'.", FormatName(person));
    MessageBox.Show(msg, "Congratulations!");

CommandViewModel CreateCommandForPerson(Person person)
    return new CommandViewModel(_selectMemberCommand, FormatName(person), person);

static string FormatName(Person person)
    return String.Format("{0}, {1}", person.LastName, person.FirstName);

Notice how CommunityViewModel only contains the logic necessary to wrap a Person in a CommandViewModel, as seen in its CreateCommandForPerson method. It does not need to handle the completion of the data access call, check for errors, marshal execution back to the UI thread, and iterate over the list of Person objects. All of that repetitive post-processing code has been conveniently consolidated in PersonDataSource. I find this separation of concerns to strike the right balance between having the ViewModel classes do too much versus having the Model classes know too much.

Revision History

  • September 7, 2009 – Published the article


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Josh Smith
Software Developer (Senior) Black Pixel
United States United States
Josh creates software, for iOS and Windows.

He works at Black Pixel as a Senior Developer.

Read his iOS Programming for .NET Developers[^] book to learn how to write iPhone and iPad apps by leveraging your existing .NET skills.

Use his Master WPF[^] app on your iPhone to sharpen your WPF skills on the go.

Check out his Advanced MVVM[^] book.

Visit his WPF blog[^] or stop by his iOS blog[^].

See his website Josh Smith Digital[^].

Comments and Discussions

GeneralMy vote of 5 Pin
stevequinn5629-Dec-10 7:32
Memberstevequinn5629-Dec-10 7:32 
NewsAdvanced MVVM Pin
Josh Smith15-Feb-10 23:08
MemberJosh Smith15-Feb-10 23:08 
GeneralCommands and the ViewModel Pin
Marc Schluper4-Dec-09 5:13
MemberMarc Schluper4-Dec-09 5:13 
GeneralRe: Commands and the ViewModel Pin
Josh Smith4-Dec-09 5:25
MemberJosh Smith4-Dec-09 5:25 
GeneralSynchronizing the ViewModel collection with the Model collection Pin
ian_duncanson2-Dec-09 19:00
Memberian_duncanson2-Dec-09 19:00 
GeneralAdvantages Pin
Asher Barak3-Nov-09 3:15
professionalAsher Barak3-Nov-09 3:15 
GeneralRe: Advantages Pin
Josh Smith3-Nov-09 5:19
MemberJosh Smith3-Nov-09 5:19 
GeneralGreat article and rather entertaining :-) Pin
DrABELL16-Sep-09 15:50
MemberDrABELL16-Sep-09 15:50 
GeneralRe: Great article and rather entertaining :-) Pin
Josh Smith16-Sep-09 17:54
MemberJosh Smith16-Sep-09 17:54 
GeneralMust have missed this one Pin
Sacha Barber16-Sep-09 4:18
MemberSacha Barber16-Sep-09 4:18 
GeneralRe: Must have missed this one Pin
Josh Smith16-Sep-09 4:18
MemberJosh Smith16-Sep-09 4:18 
GeneralA good article Pin
SteveTheThread14-Sep-09 21:44
MemberSteveTheThread14-Sep-09 21:44 
GeneralRe: A good article Pin
Josh Smith15-Sep-09 6:51
MemberJosh Smith15-Sep-09 6:51 
GeneralExample with typed datasets Pin
lucho_198111-Sep-09 8:16
Memberlucho_198111-Sep-09 8:16 
GeneralThis is "Quantam of Solace" Josh! [modified] Pin
Visu.v9-Sep-09 19:57
MemberVisu.v9-Sep-09 19:57 
GeneralRe: This is "Quantam of Solace" Josh! Pin
Josh Smith10-Sep-09 5:30
MemberJosh Smith10-Sep-09 5:30 
GeneralSilly question time Pin
Mycroft Holmes8-Sep-09 22:36
professionalMycroft Holmes8-Sep-09 22:36 
GeneralRe: Silly question time Pin
Josh Smith9-Sep-09 5:30
MemberJosh Smith9-Sep-09 5:30 
GeneralRe: Silly question time Pin
Mycroft Holmes9-Sep-09 12:43
professionalMycroft Holmes9-Sep-09 12:43 
QuestionGreat Post - What if you change a person's name, will the ViewModel's DisplayName update? Pin
Tawani Anyangwe8-Sep-09 7:15
MemberTawani Anyangwe8-Sep-09 7:15 
AnswerRe: Great Post - What if you change a person's name, will the ViewModel's DisplayName update? Pin
Josh Smith8-Sep-09 7:35
MemberJosh Smith8-Sep-09 7:35 
GeneralRe: Great Post - What if you change a person's name, will the ViewModel's DisplayName update? Pin
Tawani Anyangwe8-Sep-09 7:47
MemberTawani Anyangwe8-Sep-09 7:47 
GeneralRe: Great Post - What if you change a person's name, will the ViewModel's DisplayName update? Pin
Josh Smith8-Sep-09 8:06
MemberJosh Smith8-Sep-09 8:06 
GeneralRe: Great Post - What if you change a person's name? Pin
Tawani Anyangwe8-Sep-09 8:14
MemberTawani Anyangwe8-Sep-09 8:14 
GeneralRe: Great Post - What if you change a person's name? Pin
Josh Smith8-Sep-09 8:57
MemberJosh Smith8-Sep-09 8:57 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.