[DISCUSSION] Object Relational Mapping (ORM) for different programming languages

[Thorsten Hohage]

Hi Ruslan,

On 2007-10-10, at 22:55, Ruslan Zasukhin wrote:

> Frankly saying I understand almost nothing from this :-)
Thanks, that you're saying it "frankly" ;-)


> A lots of parameters in single place.
>
> And the main question. Above CodeStyle or XML ways define what?
>     Table + its link to some other child table?
>
> Or this is only description of LINK ?

No, it's not the description of a LINK, it's the "definition". Based  
on this definition the framework recognized that when a Value like  
"objectValues.MyValue" is requested, the "objectValues" adresses a  
linked table.

Now, with the given parameter and a lot of logic the framework loads  
the data or in most cases creates a fault, can add it on object level  
to the parent, ... and many more things. In some cases the parent  
object knows about the childs he needs to load immedeately and create  
faults of all the linked objects.

Furthermore the instantiated "Link"-object have a lot of methods,  
properties, ...



So why are the two different styles? Because the developer is lazy?!

Yes, in some sense this is true. For many requests i.e. my exhibition  
visitor management I didn't need any additional business logic, so I  
didn't need a class "Visitor" with methods. So I define a  
"virtual" (or better dynamic) "class" using (currently) a xml-file.  
During start up my framework loads all the schema definitions,  
"creates a class" Visitor and put it in my ClassFactory, of course  
the "real" REALbasic class is the defined class i.e.  
"DDOBasicDataObject".

Now I can get a new instance with (i.e)

myVisitor = App.DDO.GetObject("Visitor")


On the other hand in many cases there is a need for a "real" class to  
implement additional business logic, a good example is a "Invoice"  
class and methods like "printInvoice", "doReminder", ... Now I create  
a REALbasic class "Invoice" and inherit from (i.e.)  
DDOBasicDataObject. During start up I use a "ClassLoader"-method to  
instantiate such an object and put it in ClassFactory, too. So I can do

myInvoice = App.DDO.GetObject("Invoive")

too. If I need (or want) I can write mapper methods(getter, setter)  
to not only access the value with keyValueCoding, but with "common"  
RB style like myInvoice.invoideDate(), too.

In this second case the XML file is redundant and unnecessary and the  
given code style is used.


When I now think of a Valentina specific framework, then using table- 
methods (stored procedures inside a table) where I can call  
"invoice.doReminder" in Valentina, THEN a lot of the "real" classes  
would disappear.



Database Definition

I would be cool and would made live easier, when the framework would  
recognize, that there is a table or column missing and create it in  
the database BUT

a) even with tools (WebObjects EOF) that are able to do, I prefer the  
manual way, because I've got ways more options and chances to DESIGN  
my database instead of simply creating it.

b) There is always a difference between class types and db types,  
e.g. char(23), string(32), varchar(123), text, ... all this maps to  
String in REALBasic. So what to do? Now you can insert additional  
fields in your ORM-model to create the table. But then this model is  
tied to the choosed database. Most ORM-frameworks try to be and (IMHO  
should be) as indepent from the db as possible. So a customer want to  
migrate from Oracle to Valentina, you need to change all the models  
in the case, that you specify db type in model, too.

c) Often DB-creation and administration and software development is  
strictly divided. So it's often real wise and stressless to seperate  
the db creation/definition and the model definition.


Btw. other way is the same story. So defining a model from the db  
maybe cool for a newbie, but could be a nightmare for large solutions.


When I now think of a Valentina specific framework, this is a  
different story, too. Because Valentina already knows the datatype of  
a column and mapping column types to RB-variable-types is simple.  
When defining the model itself in the table properties and using  
Valentina ObjectLinks THEN the model will be much easier.

IMHO in this case Valentina must offer some kind of table inheritance  
(furthermore when thinking of table.methods)




Lots of parameters

As you see in the top level sample, all this parameters are hided  
from the developer. But using the basic ORM-framework it's necessary  
to set (at least some) of the parameters. But this looks more  
irritating like it is, because there are only 3 named parameters per  
"side".

And the best about them, most of them are unnecessary using the given  
Valentina types like ObjectLink and the speed of Valentina.



regards

Thorsten Hohage
--
objectmanufactur.com - Hamburg,Germany