I have a WPF application in PRISM architecture.
From what I read on the net, I saw that it is best if the View-Models call WCF service operation i n an ASYNC manner, and also - it is best to create a new connection for each operation. (I was told it is not good to keep connections alive for too long).
My question is - how should I inject the WCF clients to my View-Model ?
If I simply create an interface for the 'auto-generated' client - and inject the interface - this will simply create an instance for the client in my View-Model constructor, but that will not help me if I want to create a new client for each operation I perform in the window.
For that - I need something like a 'client factory' to be injected.
Can anyone offer his opinion on this ?
First off, IMVHO the WCF call is best to go in the Model, not the ViewModel.
You can create a factory helper class, you pass it an interface and it passes back a concrete instance that implements that interface. The factory helper can still use PRISM to resolve the interface to a concrete type, the types will resolve whatever you have registered them to, and you will get a new instance each time provided you haven't registered them with a lifetime manager.
Using PRISM inside the factory helper helps keep the whole thing highly unit testable - you can mock out the WCF related proxy classes at test time, and the target Model will never know the difference. If you really want to follow the dependency injection pattern then you could inject the factory helper on the constructor.
Related
In a recent project, we opted for johnpapa angularjs framework for a web app. Now, we want our pages to interact with web api located on the server. So, for this I have googled a bit and found that there are two approaches one is factory and other is service. And the datacontext located in johnpapa angularjs framework is a factory. So, now it looks like that all the calls we going to make to our webapi's needs to be implemented in teh datacontext factory. Which seems little messy imo. And what I want is to create a seperate file for each service/factory i.e. userSvc.js, orderSvc.js
So, is it a good approach to split the functions in different service/factory according to their logical separation. And, second thing is that do i need to create service or factory for calling webapis.
Which is the right place to call service in MVVM pattern, View Model or Model? I am planning to invoke service from ViewModel, get the JSON and convert it to corresponding model.
The reason I am not invoking service from Model to keep the Model decoupled from service.
Is this approach right or I should call service from Model?
Typically VM is responsible for making service calls. A sample call stack can be:
UI Event (View) => ICommand Execute (VM) => Service Call (VM).
It's advisable to have a re-usable Service Tier utilising the same domain objects as your app - as it allows the service-calling logic to be shared by multiple VMs (added from comments).
I think that the right place for calling a service is in Model.
The reason I am not invoking service from Model to keep the Model decoupled from service
So in this case you have your ViewModel which should handle presentation logic coupled with Service calls that probably involve data validation or manipulation.
According to
5: Implementing the MVVM Pattern Using the Prism Library 5.0 for WPF
The View Model Class:
It encapsulates the presentation logic required to support a use case or user task in the application. The view model is testable independently of the view and the model.
The view model typically does not directly reference the view. It implements properties and commands to which the view can data bind.
The view model coordinates the view's interaction with the model. It may convert or manipulate data so that it can be easily consumed by the view and may implement additional properties that may not be present on the model.
The Model Class
Model classes are non-visual classes that encapsulate the application's data and business logic. They are responsible for managing the application's data and for ensuring its consistency and validity by encapsulating the required business rules and data validation logic.
The model classes are typically used in conjunction with a service or repository that encapsulates data access and caching.
And as the previous answer showed something like this:
UI Event (View) => ICommand Execute (VM) => Service Call (VM).
I think it should be more like this
UI Event (View) => ICommand Execute (VM) => Handle Command/Action (VM) => Execute business/data logic that VM Command should have triggered (M) => Service Call (M).
You can create some kind of service helper that can be called from various models if you want to reuse service access code.
I've created a class named JsData and instantiated it in App.xaml.cs so that I can access it from multiple viewmodels. The JsData has several ObservableCollections, some properties for configuration and some methods which manipulate the process of automatically pulling data from remote server.
Now comes the question. Is it convenient for me to bind the global data to my views with minimum coding? Besides, I'm using Caliburn.Micro. Is it doable and appropriate to notify PropertyChanged events to viewmodels using messaging?
I think the best way to do this is to create a service that your view models can implement. That way on,y the view models that need the data can implement the service, and the service is more flexible because it can be injected in the view model construction. This keep your view models more decoupled and honors the mvvm pattern.
I would not use messaging to not notify changes, that would create unnecessary overhead. You just need to have your view model implement inotifypropertychanged and then get the service in your constructor And then pass the service values to properties in your view model that raise the property changed event.
If your need help defining a service just let me know and I will post a sample
I was using a simple WCF service with silverlight but I wanted to validate data with annotations and I didn't want to write a whole new layer in silverlight project. So I decided to switch to using a DomainService, created through generating code in the silverlight project.
Now comes the trouble. I have a parent class and about 10 derived classes. Through WCF, I was able to just use the base class. Now I am trying to use a DomainService with the base class decorated with the KnownType attribute. The problem is now those attributes get replicated in silverlight client and a compilation error is thrown. Anybody know how to use DomainService with inheritance? I want to deliver only the information from the base class.
I don't completely follow what your problem is, but this is a great tutorial on how to use Domain Services in Silverlight, and the example includes an abstract base class for all entities, similar to what I think you're doing.
So I have two separate views in a WPF Prism app. How can I inject the same instance of a ViewModel into both the views via Dependency Injection?
(I assume you are using Unity as you mentioned DI directly and are not saying "Import" or similar)
Hi,
You will have to register the ViewModel as a singleton (using a ContainerControlledLifetimeManager) in the container and have it injected as usual. This ensures that you will get the same instance whenever you request for it.
A valid approach in this scenario might be to use a named registration in case you want to get the same VM injected elsewhere, but you don't need the same instance.
This article explains how to do this.