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.

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;
[download]

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;
[download]

---
# myapp.yml
Model::FSS:
   args:
     service: http://soap.example.org/srvc.wsdl
     et: cetera
[download]

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;
[download]

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

• Moose::Manual::Delegation.
• Catalyst::Model::Adaptor, see mangle_arguments et cetera if necessary.
• Data::Page.
• Test::WWW::Selenium for writing tests against your Flex stuff, maybe, which would be easily adjusted to the run against the new code as well.
• catalyst+model+tutorial and Definitive Guide to Catalyst.

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 :-)

See Re: Form validation and best practice in CGI::Application / scheme of MVC