Interesting entry about ObjectSpaces in Udi Dahan's blog

Ralf (Westphal or Sudelbücher?) wrote an interesting article about ObjectSpaces that I read some days ago.

After that, Udi Dahan published a little email conversation he had with Ralf in his own blog: Objectspaces, SOA, and what comes between them.

This text appears in the entry and belongs to an email by Ralf Westphal:

I agree that the persistent stuff in a system should be kept separate, and have no functionality. In my blog I go on and on about it, so I'll keep it short here. I call this stuff "entities". The fact is that you don't just persist it, you present it too. You perform calculations with them, you make decisions based on them. The entities are what actually defines the system from a domain perspective. Fowler calls this the "Anemic Domain Model".

I actually go so far as to remove relationships between my entities. The customer entity doesn't have a collection of order entities as a property. Rather, client code wanting to get the orders for a given customer would use "Entities.OrderCollection ActivityServices.Customer.GetOrdersForCustomer(Entities.Customer customer)" to get that information. This prevents client code from having to know about relationships between entities. In the above example, there may be a 1-1, 1-n, or an m-n relationship between customer and order and client code wouldn't need to concern itself with it. Furthermore, should the kind of relationship change over time, the entity model wouldn't have to change. Neither would the client code.

The first thing that surprises me is that those guys actually still use email to discuss around their blog entries. How obtuse! ;)

The second thing that surprises me is that Udi says that the original article was written by Ralph Westphal, but I can see somebody with black glasses saying his name is Ralfs Sudelbücher when I follow the link. Confusing, eh?

The third thing that surprises me is that after talking about "Entities" that need to be persisted, presented and processed, Ralf doesn't come to the illuminating conclusion that those entities are actually the "documents" flowing through a SOA based, loosely coupled, document passing (and don't forget web enabled and buzzword powered ;), architecture.

Some years ago I built a framework based on the Emissary - Executant idea that got published in MSDN (and that soon vanished). While working on that, I saw the need of passing document-like, light entities trough the layers. By then, I had ADO Recordsets that I could be marshaled by value. Although ADO Recordsets proved to be awful, treacherous and obstinate animals, the architecture worked. It actually worked well, I think.

One little detail I would like to add, that I don't see Ralf explaining is: every time you need to use this objects, either to persist them (DAL), present them (PSL), or process them (BLL) you need some intelligent object that knows enough about the relationships, the keys and everything else that needs to be known at each stage tp handle the complexities, so you can really simplify client code.

One example of this, belonging to the data access layer, is the logic necessary to persist rows to a set of tables that have referential integrity among them.

Another example, corresponding both to the business logic and to the presentation services layer, is the logic necessary to navigate master detail relationships while iterating trough rows.

All this leaves me thinking that if DataAdapters and DataSets are not good enough, it is not because they are not well architected, but because they are not as easy to use as they could.

Now, in the deep my bottoms of my mind, the advantage of having "entities" without knowledge of their mutual relationships is not obvious. Maybe I need to sleep, but when I wrote that framework, I had relationship-less objects because all I had was ADO Recordsets. But I remember back then I celebrated the birth of ADO.NET DataSets with genuine happiness. I was already retrieving, persisting, processing and presenting all my closely related "entities" together anyway.

Tomorrow I will check orthography and also Ralf's / Ralph's real name after lunch. Promise!