Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

I need wisdom on structuring procedural code in Catalyst

by miguelele (Beadle)
on Oct 29, 2011 at 10:22 UTC ( #934576=perlquestion: print w/ replies, xml ) Need Help??
miguelele has asked for the wisdom of the Perl Monks concerning the following question:

I need wisdom on structuring procedural code in Catalyst

My status:
- I am porting a REAL working Flex application while learning Catalyst and remembering Perl
- I would like to stick to the Catalyst easiest ways before being "creative"

The structure:
- I have a Controller for "People" with subs like list, detail, edit, notify, etc
- In Detail view I get data from two sources:

  • MySql, using a Result Set
  • SOAP, from a remote app, using SOAP::Lite
  • - After retrieving everything from the two sources, data is mixed and processed (like invoices, debts or connections), preferences are applied and the right information is displayed depending of the user permissions.

    The problem:
    - As I am adding functions, the Controller is getting bigger, and I have learned that controllers must be thin.
    - The SOAP process itself also have a lot of code to retrieve and process incoming data, and I do not know how to isolate like the same way as the Result Set from MySql

    My question:
    - Where that code belongs to?
    - An Included file seems to be very ugly, or not?
    - Mostly it is procedural logic. But I imagine that a good idea should be create something like a "subcontroller" named Person, almost like a Class.

    I am really lost. Need some guidance.

    Comment on I need wisdom on structuring procedural code in Catalyst
    Re: I need wisdom on structuring procedural code in Catalyst
    by moritz (Cardinal) on Oct 29, 2011 at 11:00 UTC
      Where that code belongs to?

      Probably into the model.

      The model should be a collection of routines and/or classes which do your "business logic", ie do the actual work behind the scene.

      If you don't know whether a piece of code belongs to the controller or to model, imagine that you write another program which offers the same functionality, but a command line (or GUI) interface instead of a web frontend. Would that alternative program also benefit from the piece of code you're currently writing? If yes, it belongs to the model.

      An Included file seems to be very ugly, or not?

      There's nothing wrong with useing the modules you need.

      Mostly it is procedural logic. But I imagine that a good idea should be create something like a "subcontroller" named Person, almost like a Class.

      We don't know enough about your problem to know if that's a good idea or not. There's no inherent advantage of object oriented interfaces over procedural interfaces.

    Re: I need wisdom on structuring procedural code in Catalyst
    by Your Mother (Canon) on Oct 29, 2011 at 18:25 UTC

      You probably already have something along these lines–

      • MyApp::Schema—a collection of DBIC classes which are not directly tied to the web application and can be used anywhere without running Catalyst.
      • MyApp::Model::DBIC—a Catalyst model instantiated from MyApp::Schema + MyApp’s configuration information.

      It’s a good pattern because it gives you DB code that is not tied to your web app but is easily usable from your web app with very little code and extremely flexible configuration. So, repeating this for other data-oriented parts of the application is usually the way to go. Something like–

      • MyApp::ForeignSource::SOAP—standalone code, not tied to the web app, that
      • MyApp::Model::FSS—a Catalyst model that consumes MyApp::ForeignSource::SOAP providing the application context ($c) easy access to it.

      Your setup would look approximately like–

      package MyApp::ForeignSource::SOAP; # Some object system… Moose/Mouse/Class::Accessor use SOAP::Lite; # Collection of methods and attributes for running SOAP requests # and returning the data in nice perl structures or with iterators # and helpers like Data::Page. 1;
      package MyApp::FSS; use parent "Catalyst::Model::Adaptor"; __PACKAGE__->config( class => "MyApp::ForeignSource::SOAP" ); # If the arguments to MyApp::ForeignSource::SOAP # are a hash ref, you’re probably done. 1;
      --- # myapp.yml Model::FSS: args: service: http://soap.example.org/srvc.wsdl et: cetera

      Contrived controller example with made up methods/data/flow.

      package MyApp::Controller::SomeClass; use Moose; use namespace::autoclean; BEGIN { extends "Catalyst::Controller" } sub index :Path :Args(0) { my ( $self, $c ) = @_; my $pref = $c->user->search_related("prefs", {type => "soap"}); my $fss = $c->model("FSS"); my $stuff = $fss->call("fooBar", $fss->data->name("key")->value($p +ref->value)); die $stuff->faultstring if $stuff->fault; $c->stash( result => $stuff->result ); } __PACKAGE__->meta->make_immutable; 1;

      The arguments, methods, object design (Moose is very good at delegation so I’d recommend it for your MyApp::ForeignSource::SOAP class) and such will be details of your particular implementation but that skeleton is The Right Way® in Catalyst. Don’t forget to write tests! If you can write them against your current Flex code, so much the better.

      Reading list

      Sidenote: some Catalyst devs advocate putting the MVC components in a Web subdir: e.g., MyApp::Web::Controller::Root. I don’t and haven’t had a problem keeping disparate parts in parallel but it’s certainly a sane and clear division.

        Well, thank you. I have created some models, refactoring actions from the original controller, and they look and perform well.

        Some of them can be reused easily. Others need a level of abstraction that I am not prepared for (by the moment, of course). Moose seems to by the key

        So my plan is to move business logic to the model, at least to have it all organized for future refactoring.

        I will come back soon. As soon as my Model breaks :-)

    Re: I need wisdom on structuring procedural code in Catalyst
    by Anonymous Monk on Oct 29, 2011 at 22:53 UTC

    Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Node Status?
    node history
    Node Type: perlquestion [id://934576]
    Approved by moritz
    help
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others rifling through the Monastery: (11)
    As of 2014-12-25 03:47 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      Is guessing a good strategy for surviving in the IT business?





      Results (159 votes), past polls