Domain Context : considerations, strategies and design

1. What is a domain context?

A domain context is a collection of entities and the operations possible on those entities which is available to the client. Which the application uses to communicate with the domain service.

Client can not interact directly with domain services . Instead, a domain context class is generated in the client project for every domain service in the server project.The domain context is generated in the client side as soon as you add a domain service at the server side and build the server side project.The name of the domain context is in accordance with the domain service , for example if the domain service is called EmployeeDomainService the domain context is named EmployeeDomainContext.

According to msdn:" A Domain Context is a stateful client side representation of domain service , provoding access to all the functionality of the service."

The domain context class inherits the DomainContext class 

System.ServiceModel.DomainServices.Client.DomainContext.

2. Looking inside a domain context?

The generated domain context has three overloaded constructors:

Constructor 1: Default constructor embeds the URI for communicating with the domain service over HTTP.

Constructor 2:Enables to specify alternate URI

Constructor 3 : This is used as a custom domain context , used for unit testing.

Domain context supports:

a. Querying

b. Submitting

c.Invoking domain operations.

The Classes used for the above three operations are :

a. LoadOperation 

b.SubmitOperation

c.InvokeOperation

The Methods used for the above three operations are :

a. Load : gets the data

b.SubmitChanges : saves the changes

c.RejectChanges : rolls back changes

EntitySet is generated in the client and contains the operations(get,insert, update, delete) that can be executed by the client.

As discussed above regarding name of the service and context , similarly the name of the operations at the server side and the client side vary.

For example the server side query is GetEmployees() and client side the corresponding method in domain context is GetEmployeesQuery().

All the operations from the domain context are asynchronous and to take any action after the operation a callback method should be provided.

An application may contain one or many number of domain service and domain context.

Following are the various scenarios generally seen :

a. Application has N number of view models but 1domain service and 1 domain context.(Shared domain context.)

b. Application has N number of view models , 1 domain service but N number of domain context , one for each view model.

Now among all these scenarios which is the best of for your application how do you decide?

3. How should I Decide?

 We generally create view models based on business functionality , so creating a separate domain context for each of these individual business functionality is advantageous from the point of view that RIA services does not provide partial save. If we have separate domain contexts for each of the views we can implement partial save very easily , because whenever an entity changes for a particular business object , submit changes is called only for and not for others.

In general business scenarios normal two business objects relate to each other by some or other means , let me take an example of  two view model Product and Category. If product and category are in the same view model , we need to do extra bit to make changes in product not to reflect in category. If separate domain contexts are used , this problem can be avoided.

Although the above two points hold good but the problem that this approach has is keeping each individual view models in sync.Synchronizing each of the individual view models each time after the submit operation is a performance issue.

This does not come out of box and has to be handled exclusively. This can be done by refreshing domain contexts only for the entities that have changed.

When there is only one domain context for all the view models the problem which becomes very prominent is  the problem of partial save and also the changes in one entity will get reflected immediately.

I suggest the best way is to go with  shared domain context idea but instead of having a single domain context for all view models may be based on the UI and functionality a little more than domain context may be used.

For example , in case of a application having category, product , sale , report modules may be only one domain context will be good enough.

In case of a school management app having Student , Employee , Course , Marks, Reports we can use two domain contexts one for Student , Course , Marks and other for Employee and Reports.