I recently had an interesting support conversation with a customer at
http://www.devexpress.com/issue=Q382370. While the name of this ticket is a bit misleading (customer hoped to implement it this way in the beginning), the whole discussion is very helpful (especially for beginners with XAF and XPO), as it describes a typical business case and several solutions of it as well as their pros and cons.
Well, imagine you need to provide a comments functionality to some of your business objects, but not to all. These objects will hold a collection of Comment objects that,at once, may provide some specific properties against a type, e.g. UserComment, EventComment, etc. The most easy and efficient solution is to use inheritance here. That is creating a base Comment class and establishing a One-To-Many relationship with a base class for comments. Business objects descended from this class will automatically get the comments functionality we wanted.
While that is a good solution, it may, under certain scenarios, be inappropriate to descend from a common base class. For instance, it may be required to inject many additional functionalities similar to comments. That is, when multiple inheritance (not allowed for classes in C#) would come in handy. Good news for us that we have the great Domain Components (DC) technology! Simply said, it is ideal for these sorts of scenarios. For instance, I could easily compose the following business entity:
[DomainComponent]
public interface ICRMProduct: IGenericProduct, IComments, IWhatever
and thus emulate a multiple inheritance from these interfaces. Check the XCRM demo shipped with eXpressApp Framework (XAF) for more real-world examples.
If you are not using XAF and cannot use DC (btw, you can use DC in non-XAF applications too!), there is also another good solution for you. The idea is to compose your business object from required parts providing certain functionality using the aggregation/composition principle. Aggregation and composition in programming are very similar (the latter is a special case of the first, and I personally sometimes mix them, probably due to the misleading name of XPO's AggregatedAttribute:-)) as they differ only by the fact that in composition the part cannot live without the whole object containing it, plus, it is destroyed with the whole object as well. You can find more strict definitions of these design patterns in smart books and on the Web and this is not the subject of this short post. Well, technically, you could create a Comments Container object holding a collection of comments and then add a reference to this Comments Container to required business objects. Since a working example code is worth a thousand words, refer to the sample project I attached at the end of the Support Center ticket I mentioned in the beginning. It contains XPO classes that correctly implement that relationship. Finally, I want to mention that we use the same principle in Domain Components (DC) when emulating multiple inheritance internally.
I hope this short note was helpful and you learned a bit from it. You can learn more on business model design in XAF and XPO from the documentation.
Till next tip!