Shared Entities
[ This document was written for WCF Services Version 1 Service Pack 2 and might not be up to date
Please see Release Notes or Changelog for a list of changes since WCF RIA Services ]
Entities can be shared between several domain services within a Open Ria Services application. The same entity type can be accessed by a client through each of these domain services provided they are contained within the same server DLL. The support for shared entities includes code generation based on potentially different associations and named update methods in each of the DomainService types. The ability to share entities facilitates better refactoring and composition of larger Open Ria Services applications through simpler mapping of entities to the underlying data model.
Scenarios that illustrate the need for such sharing are common. For example, consider how personal employee information and human resource (HR) employee data could be shared. An Employee entity can be exposed through an Employee Personal Information DomainService, where employees can update their personal information such as their address and phone number. The same Employee type can also be exposed through a human resource DomainService, where, among HR information such as vacation dates and payroll disbursements, the display also shows Employee entity details such as name and ID. Another example is a product entity that is used by both a purchasing service and a catalogue service.
Note that entity sharing is only supported within a single server DLL. Any number of domain services may reference the same entity type within the DLL boundary. But sharing the same entity type across several server dlls is not supported. For instructions about how to share an entity between service domains, see the Walkthrough: Sharing Entities between Multiple Domain Services topic.
Important: Support for shared entities was introduced in Open Ria Services V1.0 SP1 and is not supported in Open Ria Services V1.0.
With the introduction of entity type sharing across more than one domain service, each DomainService that uses a given entity type contributes to whether or not a server entity property is generated on the client. The generated client entity will be a merged view containing entity properties used by the services exposing the type. The result is that the code generator will create one entity type on the client that can access each of the domain services within the application DLL. The shape of the client entity can also be affected by using the IncludeAttribute and the ExcludeAttribute attributes. The server entity property bearing the IncludeAttribute will always be reflected on the client. The server entity property bearing the ExcludeAttribute will never be reflected on the client.
Custom update methods in a domain service that have the [Update(UsingCustomMethod = true)] attribute applied to them will be reflected in the client domain context and the customer entity will contain the custom update methods associated with it. The domain context has a natural affinity to the domain service, but since the entity may not be shared, users need to be aware of which domain context to use when calling a custom update method. Intellisense should provide assistance with this.
Three limitations regarding shared entities should be keep tin mind.
- 1.Sharing the same entity type across server dlls is, as mentioned above, still not supported.
- 2.In an inheritance hierarchy, if branches of a hierarchy are shared, the same level of the hierarchy must be shared.
- 3.All DomainService objects that share a particular entity type must be in agreement on the metadata description of that type. This means that any custom DomainServiceDescriptionProvider objects for the service must specify the same metadata for the type.