[Catalyst] catalyst tutorial: MyAppDB/Book.pm vs. MyApp/Model/Book.pm

mla maurice.aubrey at gmail.com
Tue May 15 08:10:15 GMT 2007


Marcello Romani wrote:
> In MyApp/Model I usually have only MyAppDB.pm, which role is to expose 
> the DBIC::Schema classes under MyAppDB/ as a catalyst model.
> 
> This doesn't mean however that "I would never create anything" else. If 
> all I need is one dbic schema, then the answer to your question is "yes".
> 
> On the other hand, if I need for example to access two databases, then I 
> could have another dbic-schema folder (e.g. lib/MyAppDB2) and another 
> model class (lib/MyApp/Model/MyAppDB2.pm) to expose it to cat like the 
> first one.
> 
> Or I could have some other type of data that don't live in a database or 
> that I can't/don't want to access via dibc-class. In this case I could 
> write some classes under lib/MyApp/Model that directly access that data, 
> or better yet, have a set of classes (not tied to Catalyst) that deal 
> with the data and expose them as a cat model via one or more wrapper 
> class(es) (e.g. lib/MyApp/Model/ExtData.pm).

Thanks, Marcello. I think I'm beginning to understand.

The thing I was missing was that everything under Model/, View/,
and Controller/ is (relatively) tightly coupled to Catalyst itself.

So if you want a general "model" class, you don't want it in the
Catalyst Model/ directory.

I'm now trying to extend the tutorial by designing a User class, and
I'm rearranging lib/ to what seems most intuitive to me. Criticisms
appreciated.

Here's my thoughts.

The project directory is intended to hold the entire project. So
I'm expecting pretty much all of the Perl modules particular to it
to live under lib/

So as not to collide with namespaces on CPAN, we want to prefix most
everything with the project name (I'm using Try in this example).

For a generic user class, I'd therefore expect it to live in
lib/Try/User.pm

Here's the hierarchy I have currently:

$ find ./lib
./lib
./lib/Try
./lib/Try/Model
./lib/Try/Model/DB.pm
./lib/Try/View
./lib/Try/View/TT.pm
./lib/Try/Controller
./lib/Try/Controller/Root.pm
./lib/Try/Controller/Users.pm
./lib/Try/DB.pm
./lib/Try/User.pm
./lib/Try.pm

But I'm thinking a better layout would be:

/lib
./lib/Try
./lib/Try/Catalyst/Model
./lib/Try/Catalyst/Model/DB.pm
./lib/Try/Catalyst/View
./lib/Try/Catalyst/View/TT.pm
./lib/Try/Catalyst/Controller
./lib/Try/Catalyst/Controller/Root.pm
./lib/Try/Catalyst/Controller/Users.pm
./lib/Try/DB.pm
./lib/Try/User.pm
./lib/Try.pm

That makes the relationship between M/V/C and Catalyst explicit, and
leaves the rest of the namespace available for generic use.

Any thoughts?

What layouts are you folks using for large-scale projects?

Thanks,

Maurice



More information about the Catalyst mailing list