[INFO] Active Record vs Objects - Article

[Thorsten Hohage]

Hi,

as some may know I worked a lot with ORM-tools and (try to) develop my  
own in RB (long before the new -ups- (NDA ;-)) appears). So to bring  
the discussion over here and perhaps add some Valentina specific  
aspects , I'm going to write some comments here

On 2007-12-13, at 13:02, Ruslan Zasukhin wrote:

> Interesting article AND EVEN MORE interesting comments there.
>
> http://blog.objectmentor.com/articles/2007/11/02/active-record-vs-objects



There could be theoretical and "historical" two kind of applications  
that NOT have these issues in one or another style.

historical: Take a (sql-) database, use some SPs and a commandline and  
ready to go. (Of course you can extend this scenario with a nice NON- 
OO Frontend like HTML, RunRev, ...)

theoretical: Desing a pure OO-based app (and perhaps without any  
persistence at all)


All other applications designs / development environments try to move  
the break you need to cross in one or the other direction.

Using a sql-database, adding all the business logic as methods and  
sp's (THAT's the way the Valentina staff would probably shout), add a  
"connector" to PHP access the data in the "classical" way and pass it  
to the screen. There is no break, no object is created at all. Same  
may apply to e.g. RunRev or "old-style" RB app.

At least when not doing a dump style, you have some kind of screen  
components, that are reusable or simply used to make your code more  
maintainable. When you now not start to argue about words, you must  
admit that these components are nothing else then objects, perhaps not  
class instances in a pure OO way, but still some kind of objects.

Now you can start moving the break between the two "worlds". Probably  
this is one of the reasons why PHP5 was born. Now you can split the  
"components" in "screen objects", controller objects, other  
objects, ... and then there is a break to the persistence layer.

E.g. Valentina class-style in RB is moving this break further down.

There are some real OO-DBs (or should I better say OO-persistence  
layer?). For me as an db-application developer there is no break at  
all. Pure OO, but I believe the break only moved down, where a DB- 
engineer need to break his head to solve it.

IMHO at least in a pure OO-operating system, with an "OO-disc driver"  
this break is only moved inside this driver.


When following the OO-paradigm "very thing out in the world is an  
object and world itself, too" and look out of my window (object *lol*)  
and see my instance of the specific class car (more *lol*) and think  
about it, then there is a difference. A very big difference! My car is  
always alive (ok until a final destructor is called). So all the  
properties and methods and embedded objects are always kept together,  
there is no need to put it to a persistence layer and instantiate it  
back later, to deserialize it (and me, too) send all to Munich and  
serialize it, my car is always the same car-object.

So THIS is the real difference, if there would be this "Deepthought"  
where all objects keep alive for their full livetime, then there is no  
break anymore. Perhaps we should start to think about how to develop  
"Valentina Deepthought v1" ;-)


The blog post is absolutely correct, but what I'm really missing, is a  
suggestion how to do things better! Where do the author think is a  
propitiate place to make the break?


The issue with where to make the break is far more important than  
someone may think on the first view. It's about the developer, too.  
It's so easy to make a search ".findPerson("Bob")" instead of traverse  
the tree, or sending some kind of message ("Privates Smith one step  
forward!") . And in most cases searches are a clear break of a OO- 
design. It's the same like ORM, you can use qualifier-objects, ... but  
there is still a break. And of course you can make many more  
unnecessary breaks. I've seen so much bad designed software, just  
because the developer didn't get behind what good OO means.


Do I have a suggestion? I must admit sadly, not! For me a oo-db would  
do the trick, but that is only if I didn't talk about the whole thing.



Furthermore I see quite another, and for more far more serious issue,  
with all the ORM and especially with technologies like AR,  
Hibernate, ...

Most of these technologies tries to play a "little Deepthought" ;-) -  
there are several strategies how to request data, how to handle  
data, ... but no real concept how to get rid of. In every line of code  
you can see, that the target is an application server. The job of this  
server is to keep the objects alive (in cache) and take over the  
workload from the database as much as possible.

So when there is one application server to serves all the users, e.g.  
in a Web-App or other distributed environments, then everything maybe  
fine, BUT if you think about a multi-user environment in a more  
classical client/server-way it's really difficult.

A more top level break, like only using components, is easy to handle.  
You close the screen and the component is destructed. A very low level  
break, like an OO-db, is easy, too, because there is ONE server again,  
but all concept between need to solve THIS issue, too.



So more then enough bandwith is used - perhaps someone replies with  
some suggestions.


regards

Thorsten Hohage
--
objectmanufactur.com - Hamburg,Germany