It's valuable to have the model. You will get less redundant, easier to
understand/follow DB interactions and you will, if you need it, have
the DB exposed from templates and such. I don't recommend it but I was
glad to be able to write some TT code a couple weeks ago that looked
more like PHP than Perl. Having the Schema load config file stuff is
another win. No hardcoded connection stuff anywhere.
Except for a tiny performance gain, you might as well just have your
model class inherit from your data logic class; that way you don't have
to fire up Catalyst to use your data-logic-db from a command line
script or a one-off or something.
Plus, think of all the free tech support you'll get from MST. (Joking,
Matt!)
-Ashley
--
On Friday, Mar 23, 2007, at 12:25 US/Pacific, Jason Gottshall wrote:
Catalysters:
I'm developing a new app using Catalyst, with DBIC as the db
persistence
layer. I intend to build Models that encapsulate the business logic and
that will use DBIC to interact with the database as necessary, instead
of using DBIC as a "model" itself.
So if I'm not using DBIC from the controller directly, is there any
reason for me to use Catalyst::Model::DBIC::Schema? It seems like I'm
just adding an unnecessary layer of code.
Comments from any of you who have a similar setup would be especially
welcome.
Jason
_______________________________________________
List: Catalyst@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/
