You have to specify a bit more about your problem to know which way to go. So, allow me to assume you are writing a web app to manage a database.

You could use something like Class::DBI (or DBIx::Class) as your modeler. Then you would make a module inheriting from it that describes a table in your database. That's a model. It maps rows in the database to objects in memory.

Then you need a controller to take data from the user, validate it, calculate additional fields, etc. It interacts closely with the model, by creating new objects (rows) or updating/deleting existing ones.

Finally, you need a way for the user to see the process. That's the view. If you design well with a templating system, you could have a set of standard viewing templates that work for many different controllers even crossing apps. For example, in our system we have a single viewing template for virtually all of our add/edit forms. The controller populates it based on business rules (should the field be visible or calculated later, etc.) and on what is in the model (does the row exist, if so, show the user the data from it).

So, in summary, we use a model class for each table, a controller for each table (usually), and a set of stock viewing templates which are shared by many controllers (with most controllers using at least three templates: add/edit, delete confirmation, and listing of rows).

Phil