[Silverlight entry series] Using mvvm mode (8): viewmodel further isolates services

The core concepts of mvvm are introduced in the previous lecture. The mvvm mode can be used to separate views, view logic, and models to improve testability and maintainability. However, if a view is complex, review its viewmodel carefully. You will find it very huge and complicated, andPartCodeThe Logic cannot be reused. For example, another viewmodel wants to reusePartThere is no way to use the code logic instead of the whole reuse. Therefore, it is best to further separate viewmodel concerns and isolate Services to implement the iservcie interface, so that the service can do some reusable work and separate some reusable operations, in this way, other viewmodels can use services to reuse part of the viewmodel logic. The original viewmodel focus can be on User Interface interaction (binding) and view display logic. The following figure describes the relationship between the viewmodel focus and its separation:

For example, we have a logic in viewmodel that uses domaincontext to retrieve data from the WCF Ria service. Now we separate the data and call it mydataservice to implement the following interface imydataservice:

Interface imydataservice

 
1:Public InterfaceImydataservice
 

 
2:{
 

 
3: VoidGetmyentities (Action <observablecollection <myentity> getmyentitycallback );
 

4:}
 

 

Use mydataservice to implement the above Interfaces

 
1:[Export (Typeof(Imydataservice)]
 

 
2:[Partcreationpolicy (creationpolicy. Shared)]
 

3:Public ClassMydataservice: imydataservice
 

 
4:{
 

 
5: PrivateMyentitydomaincontext context {Get; set ;}
 

 
6: PrivateLoadoperation <myentity> _ operation;
 

 
7: PrivateAction <observablecollection <myentity> _ getmyentitycallback;
 

 
8: 
 

 
9: PublicMyentityservice ()
 

 
10:{
 

 
11:Context =NewMyentitydomaincontext ();
 

12:Context. propertychanged + = contextpropertychanged;
 

 
13:}
 

 
14: 
 

 
15: Private VoidContextpropertychanged (ObjectSender, system. componentmodel. propertychangedeventargs E)
 

 
16:{
 

 
17: If(Notifyhaschanges! =Null)
 

 
18:{
 

 
19:Notifyhaschanges (This,NewHaschangeseventargs () {haschanges = context. haschanges });
 

 
20:}
 

21:}
 

 
22: 
 

 
23: Public VoidGetmyentitys (Action <observablecollection <myentity> getmyentitycallback)
 

 
24:{
 

 
25:_ Getmyentitycallback = getmyentitycallback;
 

 
26:_ Operation = context. Load (context. getmyentityoverviewquery ());
 

 
27:_ Operation. Completed + = onloadmyentitycompleted;
 

 
28:}
 

 
29: 
 

30: Private VoidOnloadmyentitycompleted (ObjectSender, eventargs E)
 

 
31:{
 

 
32:_ Operation. Completed-= onloadmyentitycompleted;
 

 
33:VaR myentityslist =NewEntitylist <myentity> (context. myentitys, _ operation. Entities );
 

 
34:_ Getmyentitycallback (myentityslist );
 

 
35:}
 

 
36:}
 

Implement the idisposable interface to release memory: View, viewmodel, and service

When you create a view, you will create its viewmodel, And the viewmodel will create a service. So when you close the view, are these references still there? Will the memory be leaked? For details about how to implement the idisposable interface and how to call and release the memory, refer to my other article.Article.

Summary

When using this service, inject the service dependency (constructor injection/attribute injection) to the viewmodel.

Other viewmodels can reuse services, and services are easy to expand, maintain, and test.

By the way, in the prism framework, this service concept is used in many places. It is better to use it through servicelocator.