We are about to write our first WPF application and are becoming familiar with the MVVM pattern. We've built many Winform applications and have an architecture that has been very successful for us. We're having a little bit of trouble translating that architecture or determining where certain pieces of our architecture fit in the MVVM model.

Historically we have a Gui (the main exe) that then communicates to a BusinessLogic dll. The BusinessLogic communicates to a DAL dll through a web service and the DAL interacts with the DB. The DAL, BusinessLogic and GUI all reference the same BusinessObjects dll.

AsIs Architecture

Some of the transition to MVVM is fairly straight forward. Our Gui will still contain the views, our BusinessOjbects will still contain the model and our DAL will still interact with the DB (although the technology to implement them may change).

What we're not sure of is our BusinessLogic component. Historically this would provide functions for the GUI to call to then populate controls in the views (ie. GetCustomerList which would return a list of Customer objects or the typical CRUD functions).

The main hang up we have is whether the MVVM pattern would call for an additional component to house the ViewModels or if we just change our thinking and migrate what we have used as our BusinessLogic component to the ViewModels?

Does our BusinessLogic component represent the ViewModels?

  • This sounds a bit like a solution looking for a problem. Is there a compelling reason why you are moving to MVVM? I am a fan of the pattern but was your previous solution not working? The view model is like a supervising presenter. It contains presentation logic and surfaces data through data binding. It should know about your business logic and be able to reach out to that tier, but I wouldn't collapse business logic into the view model itself. Commented Feb 1, 2013 at 11:41

3 Answers 3


In general, I would not place business logic in the view model layer. But the term "Business Logic" is misleading.

Eric Evans uses a model where business logic is divided into two categories

  • Domain logic - Logic related to the actual problem domain you are solving
  • Application logic - Logic related to the fact, that you are building an application

He mentions the example of an accounting application. Rules about accounts, posts, tax accounts, etc. are domain rules, rules pertaining to the domain of accounting. Logic about CSV import/export has nothing to do with the domain of accounting. These rules exists purely because we are building a software application. These are examples of application logic.

Domain rules should NEVER go into the view model layer. If you are following the MVVM pattern, then the domain rules go, without question, in the model layer.

Application rules, like CSV import/export, could go in the view model layer. But personally, I would prefer to separate that out into a separate application logic layer.

The View Model should be very simple. Looking up the data needed by the view in the corresponding model, updating the model when the view changes, listening to events in the model, and propagating those events to the view, allowing the view to be updated when the model is updated behind the scenes (if applicable).

Personally I would make sure that the view model layer contains only one type of logic, presentation logic.

  • 1
    Excellent answer. I like the point of making sure the ViewModel only contains Presentation logic. Can you add any link related to your Eric Evans point?
    – user7676
    Commented Jan 31, 2013 at 23:06
  • I doubt I can find a link, because I believe I got it from his book, Domain-Driven Design. Anyway, I think it is an excellent example of the different between domain and application logic. More on the book here books.google.dk/books/about/…
    – Pete
    Commented Jan 31, 2013 at 23:23


The business logic layer is represented by the VM layer. So just migrate your mental model.

To help with your mental model migration, one slight nuance is that the GUI (View) objects should be bound to objects within the VM layer. That binding translates into | implies that the View no longer being the layer that "makes the call" in order to retrieve something else. The call for data retrieval will come from the VM instead.

To better explain: Yes, an object within the View will need to change in order to trigger the sequence of things that will make the call. But the View doesn't make the call itself. And in this case, I consider a button click as equivalent to something within the View changing, but still not making the call.

In the first case, that View object will be bound to a VM object. The VM should be listening for a property changed event on the bound object. The object change event can then be wired to a VM function to make the Model call.

In the second case (button click event), the change (click) event can be wired to a function call exposed by the VM.

Either way, it's always an event that sequences into the VM which then calls the Model which in turn calls the DAL / DB.

I bring it up because some WinForm code is used to making a call to the DB layer directly from the code-behind of the WinForm GUI. That approach breaks the separation that MVVM is providing.

  • Thanks for the confirmation. We understand the nuance of how the View interacts with the ViewModel and will keep to the binding model and drop the "calling".
    – user7676
    Commented Jan 31, 2013 at 18:18
  • I noticed that this answer lost an up vote. I'd be curious if the downvoter would comment on why? Or perhaps add their own answer if they don't share this view point.
    – user7676
    Commented Jan 31, 2013 at 18:19
  • 1
    I agree that the business logic layer is represented by the VM layer, however I think parts of your answer may be confusing. The View layer is meant to be a visual representation of the ViewModel or Model, so rather than saying the click event is wired to a function call on the VM, a better definition would be to say the Command in the VM gets rendered as a Button in the View layer. Also, I typically do not like my Model layer being able to access the DAL directly, so my application flow would typically go VM -> DAL -> DB, where the VM and DAL both use the plain Model data objects.
    – Rachel
    Commented Jan 31, 2013 at 18:53
  • 4
    I disagree with this answer. ViewModel is model of the view, it contains view logic not business logic. ViewModels are part of the presentation layer
    – simoraman
    Commented Jan 31, 2013 at 19:16
  • 1
    @simoraman - The MVPVM pattern is in alignment with what you're suggesting. I think MVPVM is a good pattern, but a bit heavy for smaller apps. I would really encourage you to put your thoughts into an answer and contribute to this question.
    – user53019
    Commented Jan 31, 2013 at 19:21

You are correct that you would essentially be replacing your BusinessLogic dll with your ViewModel layer, however I think the biggest difference you will face is how the View/UI layer interacts with your ViewModel/BusinessLogic layer.

In WinForms, the GUI is your application, and is responsible for application flow. In WPF/MVVM, your ViewModels are you application, and the GUI becomes just a user-friendly interface to interact with the ViewModels.

For example, with WinForms, you might have a DataGrid and a Button, and when you click that Button you call BusinessLogicLayer.GetProducts() and load the resulting Product objects into the DataGrid.

With WPF, you would have a ViewModel that contains an ObservableCollection<Products> and an ICommand GetProducts, and executing the command calls the DAL and loads the collection of products. But to provide a user-friendly interface for this, you would create a View which renders your ViewModel using a DataGrid for the Products collection, and a Button for the GetProducts command.

I actually wrote a fairly recent post for my blog about the change in mindset when moving from Winforms to WPF on my blog, and I think the best way to summarize the difference is with these pictures:

  • 1
    I agree with GlenH7, this is a good answer for someone starting up with WPF. We get the paradigm shift of the interaction between the View and the ViewModel so this wasn't really on topic to the question I asked.
    – user7676
    Commented Jan 31, 2013 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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