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

Marcello Romani mromani at ottotecnica.com
Wed May 16 07:46:36 GMT 2007


mla ha scritto:
> 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
> 
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
> 
> 

This seems a good approach to me (with the s/Catalyst/Web/g patch).

Thanks for the suggestion.

-- 
Marcello Romani
Responsabile IT
Ottotecnica s.r.l.
http://www.ottotecnica.com



More information about the Catalyst mailing list