Luca Bolognese's WebLog : Object Orientation

How much object relational framework do you really need?

lucabol — Fri, 06 Aug 2004 16:05:00 GMT

It is always interesting for me to look at debates about object relational layers. I propose we define different levels of object relational support:

No support: all the objects are persisted and queried by writing ADO.NET code by hand
Code generation: you run a tool on your database (or on an abstract description of your schema) and the tool generates a bunch of objects for your tables and some ADO.NET code to retrieve/persist their state

Total code gen: the tool generates all the ADO.NET code
Partial code gen: the tool generates just code to intercept property accessors and provide delay loading, but all the data access code is in a separate compiled component

Metadata based: no code generation phase. The access to fields and property goes through reflection and the data access code is not exposed in the user code

Semi transparent: the persistent classes or properties need to be marked in some special way to be persisted (attributes, inherit from a special class or such...)
Transparent: the classes don't need to be modified at all to be persisted

Things get fuzzy, though. It is sometime unclear the difference between 2.2 and 3.1 and various creative solutions can be hard to classify. But in a general sense, this classification is probably about right. In a generic sense EJB1.1-2.0 is a 2.2, EJB3.0 is a 3.1, JDO is 3.2 (if you don't consider post-compilation) and ObjectSpaces is a 3.2. Hibernate and Toplink are squarely 3.2.

But do you really need to go all the way to 3.2? All the times? I'll try to post more about trade-offs in all these solutions, but if you have an idea of a better categorization, please let me know. The one I propose is right out of my head and I'm not to happy about it either.

Book: "Objects, Components, and Frameworks with UML", Fedmond F. D`Souza

lucabol — Tue, 03 Aug 2004 20:13:00 GMT

This is a book about Catalysis, an OO methodology. I read this book some time ago (like years...). It is a quite complex book. If you don't like methodologists, it will easily put you to sleep. But if you stay awake, it is worth it.

It is strange how this book crystallized one concept for me: the definition of an interface. An interface is not just the sum of the signatures of the methods. It is a conceptual framework. The only way to fully describe it is to describe in a formal way this conceptual framework. For example without further specification it is impossible to know how to use this interface:

interface IBook() {

void AddPage(IPage p);

}

What happens when you add a page? Will it add it at the end of the book? At the start? What happens if you call the method twice? Will the pages be in order? Will they be in the same section? Is there a concept of a section?

There are ways to make explicit the implicit model beyond an interface: the one that I've commonly seen being used is documentation. The book argues for formal contracts (preconditions, postconditions, invariants). The latter is certainly more formal, but to use it you need to describe formally what is the state beyond the interface and how the different methods affect this state. It is a lot of work.

Is it worth the effort? I guess it depends on a zillion things like: the type of project, the people involved, ... I don't think anybody is actually doing it, but it is still a good conceptual framework to keep in mind when you define your interfaces: it is not enough to write down the signature methods, you have somehow to expose the conceptual framework (where somehow means more or less formally).

Please the perfect object stand up!!

lucabol — Tue, 27 Jul 2004 22:21:00 GMT

I always thought: why people write this very long posts? Here you have it.

How do I design my objects? What is the set of constraints that dictate my design decisions? People talk about objects in very different contexts. A certain amount of confusion derives from not identifying the contexts for our objects.

First, kings of them all, there are “business objects”. My library is full of OO books that describe how to design these guys. We have patterns and anti-patterns. Everybody is out there promoting their own methodology. But if we go deep enough, the most important design task in creating them is assigning responsibilities. This concept is as old as OO itself; it finds its roots in CRC cards. But I digress. Once again, when you design your business objects you have to be very careful to assign responsibilities to the objects that have the right information to perform them.

It would be nice if this was all you have to code. A crazy bigot (like me) would think that all the rest is infrastructure (ala naked objects). But we live in the real world, so let’s get down to it.

A second category of objects I often encounter are “network objects”. These are the guys you use to communicate data across tiers (logical, physical, webservices…). They are usually quite dumb objects, not too much logic in them (if any), and your application creates them by filling their properties from the more noble business objects. Something along the line of the value object pattern. Is assigning responsibilities a very important task here? Heck no!! They don’t even have methods!! The most important characteristic they have is bandwidth optimization; you want to retrieve a whole bunch of stuff in one single round trip. More often than not you sacrifice everything else (manageability, good design …) to achieve that.

This is why I don’t believe the quite common ideal of remoting your business objects. The set of constraints you use to design them is completely different (often opposite) to the constraints needed to go over the wire. When anything goes over the wire it becomes just data. Moreover not all of your business state needs to go on the network, but this is another story…

Another common object category is “database objects”. There is a big debate if they are the same as business objects or not. I dont' want to go there, but ... If you want them to be the same you usually pragmatically sacrifice a bit of OO purity to make them more similar to the database tables (you don’t want to fight your object relational mapping layer, you want to help it out). To say this in a more positive way, you design your domain model with an eye on how you are going to persist it. If, on the other end, you are willing to create a separate set of objects to represent data coming from the database, then the main constraint for these guys is the same as your database tables: normalization. This is not surprising as they are mirrors of your database. Again assigning responsibilities and being network friendly take the back seat in this case.

There are many other object categories I often found useful (i.e. façade objects). I don’t want to discuss all of them here. Things are already boring as they are. The central point is that it is very hard to define generic guidelines that work well in all the different contexts. You got to think about your context first.

The funny thing is that I work in a place where we are supposed to design features that are generically interesting in all these scenarios. You use C# to code all of them. Oh well, design is the art of choosing trade offs…