My persistent classes are real classes - or not?

When designing classes for persistence with XPO, it’s easy to be confused about certain aspects, decisions that have to be made about the layout of the class hierarchy. There are two common outcomes that typically result in problems:

1. The class hierarchy is designed without giving (much) thought to the requirements of XPO and persistence in general. I’m going to refer to this as the non-persistent hierarchy case.
2. Classes are created as pure data containers, similar to Data Transfer Objects (DTOs), without functionality, and often without being organized in any real hierarchy. This is going to be the DTO case from here on.

The non-persistent hierarchy case

Let’s look at these cases in some detail, beginning with the non-persistent hierarchy case. What are common problems here?

• Classes implement elaborate creation logic, for example by exposing various constructors for specific purposes and with large numbers of parameters, or by hiding their constructors altogether to force creation by use of static methods. This doesn’t play together with XPO well – it wants to have a constructor with just a Session type parameter.
• Properties don’t have public setters because setting property values is only allowed for constructors or a set of tightly controlled methods. XPO doesn’t like this because it needs direct access to properties when objects are being loaded from the database.
• Property setters are implemented to have lots of potential side-effects. This can be a problem because XPO uses the property setters during object loading and and when committing changes from nested units of work, which might not have been anticipated by the class designer. It can also result in performance problems, or if the potential side effects include exceptions being thrown, XPO can react to that by interrupting some process unexpectedly.
• Algorithms are implemented to work with collections of certain abstract base class types, which might end up being non-persistent when the class hierarchy is handled by XPO. It is not possible to query collections of non-persistent types with XPO, which makes it difficult to select the data for said algorithms.

The DTO case

In this case it is a bit more difficult to enumerate the precise mistakes that are being made, but essentially the persistent classes are treated as equivalents of the standard .NET DataRow – they contain data, but that’s all they are allowed to do, because all functionality relevant to that data is implemented elsewhere. This violates paradigms of OO design and the developer is wasting his time – in extreme cases the benefits of an object/relational mapping system like XPO are small or non-existent.

A warning sign for this case is usually that a very tight coupling can be detected between certain persistent types and other classes. Method calls tend to have effects in the wrong places. Consider the following piece of code:

MyType1 object1 = ... ;
MyType1 object2 = ...;

object1.DoSomething(object2);

What do you expect which objects should be changed, if any, by the call to the DoSomething() method? Right, it should be object1, more often than not. Of course the code in DoSomething() could also set properties of object2 or call further methods. But in a majority of cases, specifically when we’re talking about persistent classes (which are usually closely related to stored data), a call to a method of an object should result in some kind of change to that same object.

After this explanation it should be clear what the warning sign is that was mentioned above: if you find a lot of method calls in your application where changes occur only in the objects that are being passed in, not in the object on which the method is called, then it is very probable that you have implemented functionality in the wrong place.

So what’s the right way?

That’s the nice thing about programming – there’s never a single right way. Some ways are just less wrong than others. My suggestion is, when designing classes for use with XPO, just keep a few things in mind:

• It is not true that persistent classes don’t have any requirements of their own, above those that OO class hierarchies generally have. The list of common problems in the non-persistent hierarchy section above should give you a good starting point.
• On the other hand, don’t forget that your persistent classes are really classes, and they can do a lot more than a dumb data container can. Don’t forget you are constructing a hierarchy, not just a single class. Things like virtual and abstract methods can mostly be used in persistent classes just as well as in non-persistent ones.

Do you have any comments on this? I’m sure I forgot to mention something. Please post your feedback below!

Free DevExpress Products - Get Your Copy Today