Domain Components Overview
- 4 min to read
Domain Component (DC) interfaces are abstractions above eXpress Persistent Objects (XPO) classes. Notwithstanding its benefits, this abstraction imposes certain technical limitations. DC is only suitable for certain usage scenarios. Mobile and SPA User Interfaces are not supported for DC. DC is in maintenance mode and we do not recommend its use in new software projects.
The eXpressApp Framework includes the Domain Components Technology — a syntactic sugar developed specially for XAF and XPO. This technology provides an elegant and intuitive way for creating reusable modules abstracted away from a particular persistence layer. When using the Domain Components Technology, you basically define interfaces and XPO business classes are generated based on them. In this case, the database is managed by XPO, but you don't need to create complex code to get it to work. You specify the logic that defines how interface members behave. After that, you can reuse and combine these interfaces to quickly create the required domain components. The actual XPO business classes are automatically generated by XAF at run time.
Domain Components Technology is not by any means a replacement for the regular business classes approach for defining domain entities. The main advantage of the technology is the capability to create reusable domain libraries that contain components that can be combined in any way. If you do not need the capability to create reusable components and combine them, then it's likely that you will not need to use Domain Components - review the Business Model Design topic to see other available approaches. The following list describes the benefits of the Domain Components technology and should help you decide whether or not the approach is suitable for your task.
You can create reusable domain libraries.
Most likely, each new XAF application you develop is not unique. The most common objects, such as Person, Phone, Address, etc., are always used. The Business Class Library provides you with a set of classes that you will need most frequently. But, implementing your own reusable library is not a simple task. With Domain Components, you can easily package an assembly and reference it in your applications.
You can use a multiple inheritance.
Since Domain Components are represented by interfaces and not by classes, you can combine several previously defined components into a new one by aggregating the corresponding interfaces. The new Domain Component will expose the properties of all its ancestors and utilize their Domain Logic. Of course you can add new properties and apply additional logic.
You do not need to inherit from Base Persistent Classes when implementing Domain Components.
Each regular business class is derived from one of the Base Persistent Classes in XAF. The behavior of these classes differs. For instance, a base class can either expose an auto-generated primary key property of an integer or Guid type, or not. The choice of the base class is made once a class is implemented. With Domain Components, you can use a specific base class in each new scenario (see the ITypesInfo.RegisterEntity method overload that takes the baseClass parameter). However, attributes applicable to regular business classes and their properties can also be used with Domain Components. And of course, an object implemented via Domain Components does not differ from an object implemented in a standard way from the end-user or application administrator point of view.
- Domain Components technology does not support Model First and Database First approaches by design. We do not recommend using DC for legacy databases. Thus, we do not provide any means for generating domain component code and logic from existing databases and we have no immediate plans to support this scenario. Please try XPO or Entity Framework data models instead.
- Custom Fields cannot be added to Domain Components at design time.
- If a Domain Component is registered as a Shared Part, custom fields cannot be added.