DC: Thinking of base library

XAF Team Blog
30 September 2008

Domain Components (DC) is in maintenance mode and we do not recommend its use in new software projects.

This post is one in a series about our work on Domain Components (DC) framework and related component libraries. I’m just describing what we are working on, what problems we are facing and what results we've got so far.

The new Domain Components framework will let developers create reusable domain components. Obviously, we should supply our variant of the domain component library. Our library should be full enough to let XAF developers start fast, and to provide a common well-established base for domain component developers. At the same time, it should be flexible enough to let developers replace or extend the parts that they don’t like.

I think, in the end, we will have our domain component library derived in two parts – very specific base components, which will be reused across all other components, and common domain components, which can be replaced or extended as required. Let me illustrate this approach.

Nearly every application needs information about a person. It can be just user information, or more detailed information on a customer, or very detailed information on a legal person. Obviously, there should be a base component Person, which will be referenced and reused by third-party domain components, and a real Person component, which contains more detailed information.

Components that reference the base Person don't need much information on it. So, it may contain a FullName and ShortName, and, in rare cases, Birthday and Gender:

    public interface IPersonRef {
        string FullName { get; }
        string ShortName { get; }
        DateTime? Birthday { get; }
	Gender Gender { get; set; }

A real Person component may have more properties: FirstName, MiddleName and LastName, or GivenName, Surname and FatherName (depends on the culture). We should provide the Person that is sufficient in common cases – like this:

	public interface IPerson : IPersonRef {
		string FirstName { get; set; }
		string MiddleName { get; set; }
		string LastName { get; set; }

You can use your own IPersonRef descendant in your application, instead of the IPerson. In this instance, all domain components that depend on the IPersonRef interface will work. For this purpose, we will provide a way to tell the system that "in this application the IPersonRef should be resolved into the RomanEremin.DC.General.IRussianPerson component".

Now, we are at the genesis of creating a base domain component library, and considering an approach to implement a useful one. I think we should start writing a real-world application (this has been requested for some time). While writing, we will get core, common and application-specific components that can be included in our component library.

What application should we write? I'm thinking of a generic CRM application. Most of us are intuitively familiar with applications of this type, so we won’t need to explain much, and most of us will be able to use it.

Need Faster Support Replies?

Once you create a new XAF ticket in the DevExpress Support Center and select XAF under the Platform/Product field, please review the following help links displayed above the Submit button. These links describe how you can collect callstacks, logs and other important diagnostic information for any .NET error. Once you collect/compile this information, forward it to us along with your support ticket. This information will ensure faster and more accurate replies from support.

John Botibol
John Botibol

Thanks for your fascinating insights into the new DC technology Roman, I am an avid reader.

As a UK user I have always had issues with the base classes, they are too "American". Ideally, the base classes used by the security models should be security specific, minimal and not linked to the more general base classes. The general base classes should then be easy to remove, completely.

I think this is inferred from your blog however the link that currently exists between the classes required for security (e.g. User) and the more general base classes is a bit insidious :-)


1 October 2008

Before names for interfaces are set in stone, how about passing them by us as well.. in this short article it is already a tad nebulous regarding just one type of object: Person. Make the names clear. "Ref" means little. BasePerson might make a wee bit more sense perhaps but maybe not.

And the distinction between User and Person should not involved two separate tree branches. One definitely leads into another and currently in xaf there is a distinction between the two.

1 October 2008
Roman Eremin (DevExpress)
Roman Eremin (DevExpress)

Hi Drew,

These are thoughts, not even a compiled code, so yes, we will try to come with more meaningful name.

2 October 2008
Websites tagged "datetime" on Postsaver

Pingback from  Websites tagged "datetime" on Postsaver

25 March 2009

Please login or register to post comments.