Geek Answers Handbook

WPF Client / Server Architecture MVVM WCF

I want to create a basic wpf / mvvm application that receives data from a server with WCF and allows the client to display / manipulate (using CRUD operations) this data.

So far I have been thinking of something similar for architecture:

  • "global" level model that implements validation, research criteria and INotifyPropertyChanged contracts and services
  • some layers of services, mainly one for the framework 4 entity, implementing contracts at the model level and allowing me to access and manipulate data.
  • Please note that I want to have a standalone data source like XML or something else, and therefore another service (I plan to use some DI / IoC)
  • WCF layer
  • An extra layer to store data on the client side?
  • ViewModel

I understand the Views / ViewModel part, but I'm having trouble figuring out the relationship between the model, WCF, and viewmodel.

My questions:

  • How should I handle the model generated by EF? Get rid of it and go for the first code approach by manually doing a mapping to the database?
  • To transfer WCF data, do I have to have relational properties in my model, that is, the Product has a Client instead of a User ID?
  • Should I have an extra layer between WCF and ViewModel, for storing and processing data or is it the best Practice to directly connect ViewModel to WCF?

Any other tips for this type of architecture are welcome ...

+4
source share
2 answers

There are various solutions for the architecture of a three-tier WPF application, but there is one possibility:

1 + 2). One solution is to create “intermediate” objects that represent what your client application really requires. For example, if your application needs to display product information plus the corresponding customer name, you can create the following object:

public MyProduct { // Properties of the product itself public int ProductID { get; set; } public string ProductName { get; set; } ... // Properties that come from the Customer entity public string CustomerName { get; set; } }

Then you can open a stateless WCF service that returns your product from the identifier:

 [ServiceContract] MyProduct GetProductByID(int productID);

On the server side of your application (i.e., implementing your service), you can return an instance of the MyProduct assembly by MyProduct the database via EF (one context per call):

 public MyProduct GetProductByID(int productID) { using (DBContext ctx = new ....) { return from p in ctx.Products where p.ID == productID select new MyProduct { ProductID = p.ID, ProductName = p.Name, CustomerName = p.Customer.Name // Inner join here }; } }

3) Adding an extra layer between WCF services and ViewModel can be seen as excessive design. IMHO OK to invoke WCF services directly from ViewModel. The client proxy generated by WCF has the actual role of your model (at least one part of your model).

EDIT:

why should MyProduct refer to CustomerName instead of Customer. In my case, the Client would have many properties that I would work with. Is this “matching” too expensive?

You can use actual objects. But on the client side, since this is a three-tier architecture, you do not have access to the database through the navigation properties. If there was a Customer property attached (such as Customer ), the client would have access to theProduct.Customer.Products , which does not make sense if you cannot lazy load objects this way (without a DB context on the client side).

Compressed "intermediate" POCOs are much simpler IMOs. There are no performance issues, matching is simple, and CPU usage for this particular operation is infinitesimal compared to the database query time.

+4
source

First of all, some general information: there is a really good MVVM tutorial from Jason Dollinger available in Lab49

edit Video declares most of the needs when creating a WPF application. Dependency injection and connection to WCF are also provided (but not in depth, speaking of WCF, but with a really strong way to find good solutions here)

The source code he developed is also available here.

In my opinion, everyone related to MVVM should see this!

=> 1. How should I handle the model generated by EF? Get rid of it and go for the first code approach by manually doing a mapping to the database?

AutoMapper can help here. Codeplex of AutoMapper Your problem seems perfect for this!

=> 2. To transfer WCF data, should I have relational properties in my model, that is, the Product has a Client instead of CustomerId?

Do not mess with the model! The product is part of orders, and orders have a customer identifier. Stick to it. In your service layer, you are likely to end up with identifiers. Since you probably do not change products and customers here. If you do this (and my order order is not suitable), you can transfer dynamic data, not static.

=> 3. Should I have an extra layer between WCF and ViewModel for storing and processing data, or is it best to directly connect the ViewModel to WCF?

In most cases, I have a utility level that is introduced into my viewmodel construct in the constructor. This can be considered a different layer, since it processes the WCF client side and processes the “changed” events on the server side. (line changed, new line, line deleted, etc.)

edit If you need to send events of your service level, it is much easier to have this small, light layer between WCF and ViewModel. As soon as you have to, you are likely to come up with such a layer naturally.

+2
source

More articles:


All Articles