Archita's Blog: Domain Services

We talked about domain service in the last article, now let us sit and understand what domain service is?

Domain services are Windows Communication Foundation (WCF) services that encapsulate the business logic of an application. A domain service exposes a set of related operations in the form of a service layer.

When you define a domain service, you specify the data operations that are permitted through the domain service.

Domain service is defined at the server side, using the domain service the entities in a domain context at the client side talk to the database.

When designing a domain service, you should think of the domain service as a set of related tasks that you expect users to perform in your application. Typically, such tasks involve a small group of closely-related entities. For example, in a school management application, you might expose entities for students, grades and courses in a domain service. You might, then, place entities for staffs, class, house and payments in a separate domain service.

The DomainService class is the base class for all classes that serve as domain services.

There are two ways to create domain service class for your application:

1. Create a blank domain service for creating custom domain services

2. Create the domain service from ADO.NET.

To create a domain service that binds to a custom data object, you create a class that derives directly from DomainService.

But if you have a domain service either binds an ADO.NET Entity model or that exposes a LINK to a SQL database, there are special abstract classes the derive from DomainService that you use instead.

A domain service class must be marked with the EnableClientAccessAttribute attribute to make the service available to the client project.

TheEnableClientAccessAttribute attribute is automatically applied to a domain service when you select the Enable client access check box in the Add New Domain Service Class dialog box.

When the EnableClientAccessAttribute attribute is applied to a domain service, RIA Services generates the corresponding classes for the client project.

As a Windows Communication Foundation (WCF) service, the domain service builds upon WCF concepts.

The domain service features that use WCF concepts:

· Standard usage of WCF services

· Existing WCF programming models constructs, such as operation contracts, operation behaviors, and service behaviors

· Standard WCF customization capabilities, such as binding configuration, behavior configuration, and management infrastructure

The domain service or WCF Domain service is created at the server side.

The domain context gets created automatically at the client side.

When you build the server solution a service contract is created.

The domain context communicates with the RIA Services domain service by using the WCF ChannelFactory to create a channel and passing to it a service contract that was generated from the domain service.

By default, only the binary endpoint is enabled for domain services.

To use the binary endpoint no additional configuration is needed. If you want to use another endpoint (such as OData, JSON, SOAP, or a custom host) you must register an endpoint factory in the Web.config file as shown below:

The System.ServiceModel.DomainServices.Hosting namespace contains the endpoints that are supported in RIA Services.

A domain service generally contains methods that perform data operations that you have exposed.

When domain services are created automatically these methods are pre-added.

In case it’s a custom domain service, we need to add the methods by ourselves.

You can add methods that perform the following operations:

· Query

· Update

· Insert

· Delete

You can also add more complicated operations such as:

· Invoke: to implement operations that need to be executed without tracking or deferred execution.

This method is used only with non-entity data, and used only when query, update, insert, or delete operations cannot be used instead.

· Named Update: to implement custom operations that do not fall into simple modification operations.

When you expose a domain service, an EntitySet object is generated in the domain context with properties that indicate which operations (insert, update, or delete) are permitted from the client. You execute data modifications by modifying the entity collection and then calling the SubmitChanges method.

To Load data you should use queries instead of invoking operations because Invoke operations provide an out-of-band mechanism for returning non-entity data and executing operations with side-effects.

Query methods returns one of the following:

a. a single Entity object,

b. An IQueryable<Entity> object,

c. An IEnumerable<Entity> object.

The RIA Services framework generates entities in the client project for only those entities that are returned from query methods in a DomainService.

Following are the common things you should now before calling a query method:

a. You cannot overload methods that are domain operations.

b. You must specify a unique name for each method that can be called from the client project.

c. All methods that represent domain service operations must be public.

d. The methods must use serializable types for parameters and return types.

e. You can prevent a method from being exposed by adding the IgnoreAttribute attribute to the method.

f. A query method must return a single instance of an entity, or an IEnumerable<T> or IQueryable<T> where T is a valid entity type.

g. You cannot have two methods GetBooks() and GetBook(int id) because overloading is not allowed, instead you can have GetBooks() and GetBookById(int id)

h. When you want to write your application logic in the methods, either create a partial class or create separate methods containing your application logic which can be called from the method operations.Partial classes will give you security concerns, so use the application logic in a separate method decorated with [Ignore] attribute.