Re: O/R Mapper

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Manfred wrote:

> Also, assuming that introducing an OR framework completely hides the
> database access/product/etc. is naive at best. You still need to know
> what is going on under the hood. For instance, you probably want to
> know what kind of SQL statement is being sent to the server.

Isn't that contradicting with your statement below that it apparently
isn't important which relational model is created by the mapper? After
all, mapping classes to tables suggests that tables follow classes
which means that what you're doing with the classes would drive the
structure of the tables, as the tables are just storage for what you've
written in code.

> > From a project I can remember a case where a simple method retrieved
> two strings from the database. As the team didn't have a lot of
> experience with the OR tool the just did what they thought was the
> straight forward approach. In the end the SQL statement was a join
> over a dozen tables and extremely slow. In the particular case the
> issue was solved with a fairly simple stored procedure wrapped by a
> simple method call.
>
> As a side note: beware of people who think that mapping tables to
> classes is identical to mapping a good object-oriented design to
> tables, and that you end up with the same set of tables in both cases.
> It usually raises a red flag if someone does not know the difference
> between a class diagram and an ERD.

again, claiming things without proving why isn't helping the
discussion.

Let me help you, as I'm getting pretty tired of claims from people
without any proof. If you have something to say about which is bad or
good, explain why or don't claim things.

Let's say we define the following entities in the scope of our
application (among other entities):

Employee
Manager (subtype of employee)
BoardMember (subtype of manager)
CompanyCar
FamilyCar (subtype of CompanyCar)
SportsCar (subtype of CompanyCar).

We also identity the rule that only a boardmember can have a company
car.

If you use niam/orm you'd define a supertype employee, then a subtype
manager, then a subtype of that of boardmember. you also would define a
supertype companycar and 2 subtypes of that called familycar and
sportscar. You also would create a m:1 relation between boardmember and
companycar, as that would realize the rule that only boardmembers can
have a company car.

You can do the exact same thing in UML.

No tables have been created yet. Ok. Creating tables from this
abstract model creates an interesting question: you can model
hierarchies in 2 ways: every subtype in a separate table with a 1:1
relation over the PK, or you can flatten the hierarchy and store
everything in a single table with a discriminator column (there are
other ways, which are actually combinations).

As there is a relation between boardmember and company car which is
thus non-existend for manager and employee, it's better to opt for the
1-table per entity modelling. However for the
companycar-familycar/sportscar hierarchy, it doesn't matter, so we
flatten that hierarchy.

The tables we end up with are:
- employee
- manager (fk on pk to pk of employee)
- boardmember (fk on pk to manager, fk to companycar)
- companycar (with discriminatorcolumn cartype)

so 4 tables instead of 6.

Now, lets say the system architect uses niam/orm or other abstract
modelling technique and created those 4 tables. We then use the
table->class approach and what do we get?

4 entities.

So we mis 2. Now, from an OO's perspective, this is lacking, and I
fully agree (in LLBLGen Pro, you can re-create the complete hierarchy
as I explained earlier on, easily, recreating the complete abstract
model as it was intended, so at first it finds the 4 entities, and the
hierarchy of employee-manager-boardmember, and you create teh subtypes
familycar and sportscar).

Though what's the real deal? Isn't it so that all this is rather
semantic? If I have just 4 types, and just a companycar, is that
preventing me from writing software that works? No not at all, because
people are writing software with that paradigm for over 3 decades now.
It's just that it isn't that EASY to work with, because you can make
mistakes (if you don't interpret manually the cartype value, you might
treat a companycar row as a nice sportscar while it's a lame familycar!)

Though never forget: the data in the rows in the db are just data, and
get their semantic value in the sense of inheritance and what TYPE they
represent, by the context they're read. This means: beyond the type
offered by the relational model, as 'companycar' is the type offered by
the relational model but the types we're looking at are based on
semantical interpretation of a value in a column, not by the structure
of the type offered by the relational model.

Is the approach of using a proper relational model as the basis of
your application that weird though? No, as I just described, the
abstract elements which are used as building blocks are effectively the
same, be it an entity in a niam model or a class in an UML model. The
UML model combines behavior with teh data structure, the niam model
doesn't but that's a difference not really important for the structure
of the model.

Now, did I end up with different tables than a person who would have
started with UML? No. Employee, manager and boardmember are all mapped
to their own table. companycar, familycar and sportscar are all mapped
to the same table.

perhaps the cause of all this is the difference between datamodel and
relational model, I'm not sure. I hope people now realize what the
differences are between using an entity model vs using a pure table
model and can make their decision which one to choose.

For the record: I always talked about entities and the relational
model of entities, not about pure tables, as I've described above, you
can have multiple entities with just 1 table.

> Bottom line my suggestions would be:
> - Depending on your project size run a little experiment with
> different approaches, determine selection criteria, and finally
> decide on the make-or-buy decision.
> - If you roll your own mapping, you should be extremely confident that
> you can do better that those who implemented the available frameworks,
> or you should have an excellent justification.

As a person who now works for 3 years full time on one of the
marketleaders, I can assure you: writing your own is simply too time
consuming: even if you just implement the very basic mapping code, its
still a lot of work, and also unnecessary, simply because there are
enough different o/r mappers out there which are solid and mature and
all have their own POV on the matter so it should be easy to find that
o/r mapper which fits the way you want to work with data.

I tried to write a little article on that some time ago:
http://weblogs.asp.net/fbouma/archive/2004/10/09/240225.aspx

Personally, I don't think anyone is helped with 'this is good' and
'this is bad' kind of babbling, simply because there isn't a silver
bullit. People who are perfectly comfortable with sql, table focussed
database access etc. have a hard time with DDD and o/r mappers but feel
at home with stored procs and datatables. We all can try to lecture
them that they're doing stupid things and use bad practises
(exxagerated) but at the end of the day, if they have succeeded in
writing a working succesful application, we're not justified to lecture
them, because they did manage to write a proper application.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.

Relevant Pages

  • Re: Is this too much OOP?
    ... and companycar in the Employee class, ... property 'ManagesDepartment' and 'CompanyCar'. ... The problem here is that a manager is not a special type of employee, ... a biz app. ...
    (comp.object)
  • Re: Is this too much OOP?
    ... inheritance in your framework, like with the Employee class. ... 'ManagesDepartment' and 'CompanyCar'. ... The problem here is that a manager is not a special type of employee, it's an employee that has a special role - possibly at a given moment. ...
    (comp.object)
  • Re: Is this too much OOP?
    ... is a base employee class. ... when a Manager or line staff employee derives from the employee class. ... About inheritance: in general, inheritance shouldn't be overdone. ... 'ManagesDepartment' and 'CompanyCar'. ...
    (comp.object)
  • Re: Is this too much OOP?
    ... and companycar in the Employee class, ... property 'ManagesDepartment' and 'CompanyCar'. ... members of subtypes, like the reference to companycar or department. ... Still place the 'managesdepartment' association in Employee? ...
    (comp.object)