[Dbix-class] Moose

[David Ihnen]

On Sun, Jul 18, 2010 at 7:40 AM, Leandro Hermida <softdev at leandrohermida.com
> wrote:

> Hi t0m,
>
> On Sun, Jul 18, 2010 at 6:22 AM, Tomas Doran <bobtfish at bobtfish.net>wrote:
>
>>
>> On 11 Jul 2010, at 14:48, Leandro Hermida wrote:
>>
>>> I had a look at KiokuDB, its a very nice project and suitable for
>>> certain needs, but it doesn't do ORM. In many software development
>>> projects particularly business-related you really the database to be a
>>> relational implementation of your entity object model because you have
>>> other systems, software and programming languages that will be
>>> interacting with the database.
>>>
>>
>> Unless you're going to hide the entire actual DB behind views and stored
>> procedures, then this is generally a REALLY BAD IDEA.
>>
>> You now have no level of abstraction from your database layout and your
>> data model.
>>
>> Which means that changing the database layout (without changing all the
>> apps which work on that layout at the same time) is going to break thing=
s,
>> which then need fixing in multiples places, and releasing in sync - I.e.=
 you
>> just achieved very very close coupling to your DB schema, which you want=
 to
>> avoid (for reasons stated above) if possible...
>>
>>
> very good points and makes a lot of sense.  If I can ask a more general
> question then, why do ORMs exist in the first place and why are they so
> popular vs using a object persistence mechanism?  There must be some seri=
ous
> advantage to using them.
>

Actually the poster is misleading.  When you change the database layout you
don't have to change the apps which work on that data model interface -
because you already have an abstracting layer between the application and
the database.  You can extend your ORM implementation to be backwards
compatible, so that the actual data store behind it can change but the front
face does not.  Some find it convenient to have a data model layer between
the app and the ORM, but it is not necessary, only one layer is needed.
 ORMs exist - their killer application - because it is difficult enough to
manage your model layer abstractions - which exist regardless of ORM or not
- without adding the further complexity to them by changing your semantics
into into a new language - SQL in this case.  You also bypass the flat
table-space paradigm of SQL making your data objects hierarchal per your
defined relationships without having to go through the tedium of translating
the flat space to the hierarchal space.

"But we're comfortable with SQL in our programs!" people shout, that is the
way it has been done!  It shouldn't be.  No more than you should output HTML
through print statements in a CGI program!  That is a language in a
language.  You should be able to interact with your data source on a native
language level, and this is what the ORM provides.

How much code have you written that forms sql up from chunks relevant to a
certain type of query?  How much code have you written that builds sql table
data form returns into various types of objects?  Even hierarchal logical
ones resulting from a one-to-many join?

There is a type of code you don't have to write when you use an ORM -
because all that SQL abstraction is done for you already.  Your interface is
as stable as you want it to be, your application does not have to change
when the data store changes - only the model layer between them.

- keep the sql out of my perl
- keep the data store interface separate from the application
- no reinventing the wheel for data store to object instance translation

David

-- =

"If only I could get rid of hunger by rubbing my belly" - Diogenes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100718/e8e=
980b0/attachment.htm