I have come across this thought from my fellow monks in the past, yet I still can't seem to see how, possibly not seeing the woods through the trees.

In my example, a My::Customer may work in a My::Industry. They'll need to select a My::Industry on a form.

This all leads me to needing to get a list of possible industries, and tying the two together through their IDs.

Somewhere else I may need to get all My::Customer objects that registered last month, last year, 2 weeks ago, etc, hence the need for some sort of...

My::Customer->get( registered => [ DateTime->new( year => 2011, month 
+=> 4, day => 1 ), '>' ] );
[download]

...approach.

I'd love to sit down and talk this idea of modelling processes more than the objects themselves with a fellow monk, but unfortunately I currently work pretty much alone, while training up 2 others.

I presume my original approach to be "ok", I think I've asked a similar question before and it usually goes on this same tangent of the modelling rather than the interface.

Somehow, I do not like the '<' string. Cannot you supply a sub ref that will return the values you need, i.e. similarly to sort:

My::Customer->get( registered => [ DateTime->new( year => 2011, month 
+=> 4, day => 1 ), \&greater ] );
[download]

You can than define between etc.

Me neither, that string isn't very nice.

An interesting approach you suggest, this is what I was after! :)

Tho that does make the code look a bit messier - maybe some more encapsulation around it...

My::Customer->get( registered => [ $datetime, My::Operator->greater ] 
+);

package My::Operator;

sub greater
{
    return '>';  # or something more fully fledged!
}
[download]

Indeed. I'll chime in with the reassurance that there's little "wrong" with the modelling of 'physical' objects.

It tends to be a bit heavy weighted later on. But refactor it a bit at a time. For instance, everything you describe sounds ok. But I don't have to work with it, so it's tough to figure out where the sticking points are. All I can really advise is to pay very close attention to "I wish I could just...." thoughts. Optimistically write it top-down as far as you can, then the design difficulties will emerge in a pretty clear way.

Either way, sounds like your thinking on the right lines.

Me

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).

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

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.