CODEWITHSUNDEEP
wpfmvvmn-tier-architecture
Adolfo Perez
Adolfo Perez

Reputation: 2874

MVVM WPF application in 3-tier architecture

I'm currently working on a Enterprise WPF LOB Desktop application using the MVVM design pattern. My current Solution structure in my development machine is the following:

I'm currently not using WCF since everything resides in the same machine at this moment except the database which is in its own server. However, in the future we are planning to split the code-base into 3-tiers.

The problem I have is that one colleague insists that we should split our application as follows in 3 separate servers/machines:

  1. Presentation Tier - The client WPF application (View) in users machine. This may as well be a Web client application
  2. Logic Tier server - The View Model + Model + Business Logic Layer + Data Access Layer
  3. Data Tier server - The database server

I cannot conceive the View Model living apart(different server) from the View and he claims that should be possible.

EDIT: My colleague claims that having the View Model in the Server side will ease any future deployments and will make it more maintainable because changes would go only on the server side. However, I've deployed .NET applications using ClickOnce and it is not really a big deal.

From what I have read you can have a WPF client application installed at users computer which contains the View and ViewModel and then expose the services at lower layers through a communication layer like WCF.

This answer in another posts states the following: "In MVVM the UI Layer is separated into two layers. the ViewModel, which is in charge of the Application Logic, and the View, which is in charge solely on presentations." Based on that, my fundamental question is, can the View and the ViewModel UI layers reside in separate tiers (servers)? If so, is that recommended? and how could that be accomplished?

Thanks!

Upvotes: 4

Views: 8238

Answers (2)

Blachshma
Blachshma

Reputation: 17395

The View Model, call it how ever you want, is at the end an instance of an Object held in the memory of your computer. Just like any other instantiated class. Its purpose is to connect the View and the Model, access various BL methods, etc.

Even if it is feasible to pass an instance of the View Model from some server to the client (Let's say you binary serialize it on the server and deserialize it on the other end) - Other then creating a huge overhead (both on the Network and on the CPU), I can't see how it will possibly make things easier, on the contrary I would like to understand how is this going to make things more maintainable.

Both the View and the View Model should be on the client side. e.g.

Presentation Tier - The client WPF application (View + View Models)
Logic Tier server - Model + Business Logic Layer + Data Access Layer
Data Tier server - The database server

Given this separation, he is correct that changes made in the BL or DAL will not need to create a new version of the client (as long as you don't break any interfaces, don't change the model etc.)

Upvotes: 7

Faster Solutions
Faster Solutions

Reputation: 7005

Lets start with the obvious:

  1. ViewModels don't live on the server. Their role is to make data from multiple services/models available to the view and provide the link between views and data. Nobody does this and nobody will think this is a good idea. Ever.
  2. Your data tier can live wherever you want it to live with minimal intervention.

Where there will be discussion is how much/little of your business logic tier is is moved up to become a WCF layer and how much will remain on the client machine. This is what the discussion should be about.

If your colleague persists on arguing that the viewmodel should be on the server ask him/her to prototype it. It should be highly entertaining.

Upvotes: 1

Related Questions