4

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:

  • Main Project - WPF application containing all the Views (XAML)
  • View Model - Contains all View Models backing up the Views in main project
  • BLL - Business Logic Layer
  • DAL - Data Access Layer - Connects to a MS-SQL server and calls Stored Procedures
  • Model - Contains all business entities

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!

Community
  • 1
  • 1
Adolfo Perez
  • 2,834
  • 4
  • 41
  • 61
  • Please note: "View Model" and "Model" are two different things. I am sure he didn't insist on having the "View Model" on a different machine than the View. – Daniel Hilgarth Dec 12 '12 at 13:19
  • Sorry I corrected that. Yes, he insisted in having the View Model on a different Machine, that is what I have a very hard time to conceive! After all I've read nobody ever suggested that. – Adolfo Perez Dec 12 '12 at 13:20
  • 3
    In that case, ask him how he imagines this to work. It is a bad idea that will make the View Model useless. – Daniel Hilgarth Dec 12 '12 at 13:21
  • I think it is not good idea to move ViewModel to service side, I didn't understand the reason you want to move it to service side, could you please explain? – Arsen Mkrtchyan Dec 12 '12 at 13:24
  • Look at my edit in the question. He claims that moving the ViewModel to the server side will ease deployments, changes/fixes, and make it more maintainable – Adolfo Perez Dec 12 '12 at 13:28
  • 3
    Tell your colleague he's nuts – Big Daddy Dec 12 '12 at 14:48
  • Several of the developers where I'm currently working have had a good chuckle about your colleague's suggestion. – Faster Solutions Dec 12 '12 at 15:22
  • I know... glad I'm not alone. It stops being funny when you realize he is the application architect. – Adolfo Perez Dec 12 '12 at 15:33
  • 2
    It sounds like he is getting MVVM confused with 3 layer server client architecture, they aren't quite the same thing – Alan Dec 12 '12 at 16:29

2 Answers2

7

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.)

Blachshma
  • 17,097
  • 4
  • 58
  • 72
1

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.

Faster Solutions
  • 7,005
  • 3
  • 29
  • 45