in reply to Trying to understand Catalyst::Model::Adaptor

as opposed to just requiring the external module in the controller and using it directly.

This is a good question but you'd only ask it at the beginning. After skipping the model approach and ending up with use XYZ; configure_xyz(); etc_xyz(); in a couple or a couple dozen controllers and then deciding to make a simple change or replace XYZ with ZYX you see how much saner models are than beefy controllers.

Ultimately you can do it the way you like best of course. Putting code in controllers is a slippery slope and encourages more of the same instead of splitting out things where they can be reused without duplication.

Replies are listed 'Best First'.
Re^2: Trying to understand Catalyst::Model::Adaptor
by tospo (Hermit) on Apr 06, 2010 at 08:51 UTC

    thanks for your reply. I think I might need to clarify my question a bit. I don't doubt the MVC pattern itself and I don't want to put business logic inside the controller and . In my example, my business logic is in NonCatalyst::MyClass, i.e. it is completely separate from the controller and the WebApp itself. The controller simply collects data and asks this model class for a result, which it then sends to a view.

    My question is, what do I gain from using the Catalyst::Model::Adaptor approach to declare my external class as a model as opposed to simply requiring it in the controller and using it directly. If anything, the Adaptor approach appears to require more code, especially when parameters need to be send to the model.
    In addition, my case requires that the model is instantiated once per request (it needs to connect to third-party databases depending on user input), so I would have to use Catalyst::Model::Factory::PerRequest and I can't really see the benefits of that at the moment but I'm new to Catalyst and fully aware that I might be overlooking something here. Thanks for your help!

[reply]

      I think you're asking good questions and you know what you're doing because you already found and understand why Catalyst::Model::Factory::PerRequest exists. I do think I answered you pretty well, though. :) If it can be done simply, directly, and in one place, write it in the Controller class. If it is going to be used in several places, use the Model approach.

      Part of the what the Model approach buys you is that the instantiation of objects can be done/extended/augmented through config. You can actually do this with Controllers too but I find it less graceful and it will again result in extra code if it's not in exactly one Controller.

      If doing it in the Controller feels natural, go for it. It might be the fastest way to get going. Revisit if it starts to feel messy or like it's making extra work.

[reply]

        OK, thanks!

        In my case, I don't want to tie the instantiation of the model class too tightly to the Web App because I want to use it as a back-end for command line scripts as well. I guess that means I should use my first approach and simply require and use objects of the external model class directly in the controller without using any Model Adaptor.

[reply]

In Section Seekers of Perl Wisdom