DC: Interfaces and BOModel

This post may be outdated. For the latest Domain Components concepts and examples refer to the current online documentation.

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.

Now, while I’m waiting for the XPO team, who promised me to support new requirements, I've found one more problem. In my BOModel node, I can see the IDeveloper and INote interfaces, but I can't see the IPerson interface. Since our ultimate goal is to provide the ability to create reusable domain components, I want to be able to set up all XAF-related aspects of the IPerson in the Application Model, and then reuse these settings in all places where the IPerson is implemented.

But should I add all interfaces to the Application Model? What if the IDeveloper is inherited from the IDisposable, in addition to other interfaces? Should XAF add the IDisposable to the BOModel node? I guess not. There should be a way to mark the interfaces that are used for building entities later. I decided to add the DomainComponentAttribute that will serve as a mark:

	public interface IPerson {
		string FirstName { get; set; }
		string MiddleName { get; set; }
		string LastName { get; set; }
		string FullName { get; }
		DateTime Birthday { get; set; }
		Gender Gender { get; set; }

Now, after I've refacored the code that analyses types inside XAF, the interfaces that use the DomainComponent attribute are added to the BOModel node:


4 comment(s)

Hi Roman,

Would we be able to modify some of the IPerson model settings in the DC's that implement IPerson. E.g. could an IDeveloper Birthday have a different Date format to that of an IContact (that also implements IPerson)?


30 September, 2008
Roman Eremin (DevExpress)

Hi Jacha,

Currently answer is no. Every node in BOModel have only own properties, so IPerson's members will be listed there only once. The same true for class inhertence in XPO 8.2.

Do you have a real scenario that requres this or is it just a theoretical question?

30 September, 2008

Hi Roman,

I asked the question because I have come across this problem in the past. On my base class I have the common DateCreated / Modified properties that I set to a fairly verbose default format. For certain descendents, this format is not appropriate and currently I have to modify the format on specific views. Not a big problem in itself but I am sure there are other scenarios where changing a model setting on an inherited property would be desirable. I think that it may be helpful to view this as a form of inheritance within the model where you can override ancestor "static behaviour" in descendents as necessary in the same way that you can with certain attribuites in code.


1 October, 2008

@Jascha: i absolutely concur.. this way one could create simply defaulted values that traverse a tree but are modifiable where required. This is very similar to our requests that listview and detailview settings for BO's have a BOModel parent to allow us to make general and wide-sweeping changes that can be overridden where required but not forcing us to set each end node within the tree..

1 October, 2008

Please login or register to post comments.