Re^2: Design Question - I've gone object mad!

Just a quick addition, the My::Customer object will translate columns, join multiple tables together, etc, to return a fully fledged My::Customer object.

I'm not just blindly modelling a database table.

Like I say, this modelling is, in my eyes, a layer above the database model (if i were to introduce DBIx::Class, for example).

Comment on Re^2: Design Question - I've gone object mad!

Replies are listed 'Best First'.
Re^3: Design Question - I've gone object mad! by Your Mother (Archbishop) on Apr 07, 2011 at 05:00 UTC
From this particular description it sounds like you misunderstand what DBIx::Class does out of the box and what it can do with plugins/customization. Have you tried it? Do you know it does all those joins and such, in deep, flexible, beautiful ways with chained resultsets, and can do things like manage transactions with nothing but variable scope? Twice in the last few years I’ve been stuck with legacy code written under the auspices of NIH syndrome and I really hold a grudge against the developers who made those choices and wasted weeks and weeks of my time that could have been productive, just chasing bugs and dealing with edge cases. For the future “me”s out there, I’m begging, investigate your options. There are many. Perl ORM comparison (Class::DBI vs. DBIx::Class vs. Rose::DB::Object) Re: Creating Moose Classes to Interact with mySQL/Oracle	[reply]
Re^4: Design Question - I've gone object mad! by Cagao (Monk) on Apr 07, 2011 at 08:16 UTC
Hi Mom, I'm sure I'm aware of DBIx::Class and what it can/does do, but again it is natively tied to a database, something we may not be using in the future, so for that reason, I am modelling above the database/dbix::class layer. My models may well use DBIx::Class internally when they are talking to a database, but that is internal. Hopefully you see now that I am designing a layer above the modelling of the storage engine being used.	[reply]