[Catalyst] ways to do stuff and why

[Brian Kirkbride]

leonard.a.jaffe at jpmchase.com wrote:
> Brian Kirkbride <brian.kirkbride at deeperbydesign.com> @ 08/18/2006 01:57 PM:
>  > At this point, if I want code reuse I have two reasonable choices:
>  >
>  > A) Create business logic modules, ie. MyApp::Logic::CreateTrial, etc
>  > B) Write my own business logic methods in 
> MyApp::Schema::Trial->create(...)
>  >
>  > Either is valid and from what I gather Java developers like the Logic 
> route.  I
>  > chose (B) because I already have the classes and the logic is 
> *usually* just
>  > operating on that class's data model.
> 
> [Insert snarky Java comment here]
> 
> B couples my business logic too tightly with the ORM. ORMs fall out of 
> fancy.
> The whole point of MVC is loose coupling. Method A does not have that 
> tight coupling.
> This is a bit of good advice I've picked up along the way:
>      Loose coupling of objects.  Code to the abstract class (API) not 
> the implementation.
> 
> Sometimes it helps to forget about ORM's for a minute.  The hash or 
> array of data returned
> by DBI is still your Model.  It you want objects, you have to roll your 
> own, around the DBI data.
> Roll your own around the DBIC data, use object composition, rather than 
> inheritance.  The coupling
> is looser, and that makes your code less brittle.
> 

I'm leaning toward this as well, you might have convinced me with the 
composition argument.  I had been thinking of it in terms of inheriting from the 
model.

I've moved from a home-grown ORM to Class::DBI to DBIx::Class in this project's 
history.  The business logic methods in the model classes had to change each 
migration.  Not a big deal, because it usually changing ->find to ->retrieve or 
something that simple.

But not having to ever change a controller, script or CRON job by way of a set 
of Logic:: proxy classes would be nice.  Generally these bits don't have to know 
much of anything about the model implementation so it hasn't been much to 
change.  But when iterating over result sets it's hard to avoid the model 
implementation specifics.

Maybe I'll spend the weekend whipping up some proxy classes to sit between my 
model and the rest.  I that the business logic methods in the model would be 
moved into these classes as well.

Thanks!
- Brian