package Model::Classloader;

sub new { my $pkg = shift; return bless {@_}, $pkg }

sub class {
    my $self = shift;
    my $class = shift;
    my $fullname = $self->{namespace} . "::$class";
    eval "require $fullname;";
    return $fullname;
}
[download]

Here's an example for your code:

package MyApp::Frontend;

use Module::Classloader;
our $C = Module::Classloader->new(namespace => 'MyApp::Adaptor');

sub get_report {
    $C->class('Report')->get_report($report_id);
}

package MyApp::Adaptor::Report;

use Module::Classloader;
our $C = Module::Classloader->new(namespace => 'MyApp::Backend');

sub get_report {
    # some business logic such as check if report exist, etc. 
    $C->class('Report')->get_report(...);
}
[download]

By the example you've used, you may be trying to put too much into your model. A report would be a view of the model, so you wouldn't use MyApp::Backend::Report. The model should concern itself with ensuring that the data remain in a consistent state WRT business rules, etc. I know that was a one-off example and it may not be what you meant, but I thought I'd mention it. In general, I try to keep a model as simple as possible. So when I'm adding a method, I ask myself ... "Is this necessary? At the right level of abstraction? etc.".

Definitely agreed on keeping view-related things in the view, but IMHO you really want to (as much as possible without breaking the layer abstractions) put as much as you possibly can into the Model layer.

Think of it this way: the Model layer *is* your application, in an abstract sense. It is your application without any regard for specific output formats or input methods. So if part of your application involves generating summary reports of database data, there probably should be a model class/method which handles report generation.

However, it should only generate the report data based on abstract input parameters, and not deal with any user parameter input or user output formatting. An appropriate controller would gather user report parameter input from an HTML form or an emailed form (or a voice-prompt UI over a telephone), and an appropriate View would transform the report data into HTML or PDF (or text to speech) or whatever output flavor of the month.

Your frontend class, adaptor class, and backend class should be derived classes of the same base class. Then they can inherit the same get_report() member function. That way get_report() is only declared once.

every adaptor class is loaded as a component of the frontend base class. at application startup, every component is required and instantiated via new(). The instances are then stored as a class data of the frontend base class, making them some sort of singleton objects.

package MyApp::Component;
use base qw/Class::Accessor::Fast Class::Data::Inheritable/;

1;

package Frontend::Base;
use base 'MyApp::Component';
__PACKAGE__->mk_classdata(components);

sub load_components {
    # use module::pluggable
    # for each adaptor that module::pluggable found
    # load the adaptor($comp)
    $class->load_component($comp);
}

sub load_component {
    my ($class, $comp) = @_;
    $class->components->{ $component_name } = $comp->new();
}

sub adaptor { 
    my ($class, $model) = @_;
    return $class->components->{ $component_name };
}

1;

package Frontend::Report;
use base 'Frontend::Base';

sub do_report {
    $class->adaptor('Adaptor::Report')->method;
}

1;
[download]