• Having multiple developers work on a single file is only a problem if you have no version control, or are making massive changes.
• A well-written CGI::Application module would not have much in the main class. It would be calling other classes to do most of the work. The main class just translates web requests into method calls on other classes.
• Any project large enough to have a team working on it will have multiple CGI::Application modules. I like to split things up into logical "applications" so that if Jane is working on the address book app and Jim is working on the calendar, those will be separate modules.
• In practice, I've never had a problem with teams using any kind of MVC approach like CGI::Application.

My experiences with CGIApp are very much in line with what perrin's is stating. If you break up your runmode modules into logical tasks, you will end up with a whole bunch of modules with only about 3 or 4 runmodes in each. If you start noticing that you have 10 - 15 runmodes, then perhaps you should think of break this into smaller pieces.

One thing that some users find annoying about breaking the application up into smaller pieces like this is that you require a small CGI script for each of your runmode modules to fire up the application. We have found that using the CGI::Application::Dispatch module really simplifies this by having a single CGI script (or mod_perl handler) that can spawn multiple runmode modules based on the PATH_INFO of the request.

Also, I find that most of the logic in any of the larger CGI::Apps I have built tends to fall into the Model of the application. Most of the runmodes tend to be quite simple and generally just pass data between the Model and the View, with a bit of data validation thrown in.

If you decompose correctly, you shouldn't be working in the C::A hierarchy unless you're changing user interactions.

The trick is to figure out which parts of the system going into which part of the MVC (Model-View-Controller). In my experience, most of the work ends up in the Model part, which doesn't really care why or how you are looking at it. It's general code to do all of the interesting work without thinking about how you actually look at the data or how you tell it what you want to do. Above that is code to take those results to show it to us (the View) and other stuff to let us make it do things (the Controller). The V and C portions really aren't all that tough: they translate our requests into things the model can do, the translate what the model did back to our environment. They are really just adapters between our application and the Model.

Things don't end up in a single file because the idea is that there is no monolithic application. The Model should be able to use any View or Controller. It's not just a web application because it could be a SOAP thing, or a terminal interface, or something else. The Model should exist separately from a particular use of it.

Once those things are decoupled, people can work on the different layers and different parts without colliding with each other.

Newer MVC approaches like Catalyst and Ruby on Rails put more logic in the Controller (they support multiple controllers) than the classic ones, which results in a more balanced architecture.

Oh yes, and i suggest SVK for teamwork.

As dragonchild pointed out, your main business logic (model) can be in separate modules/packages to your rum modes (controller)

In addition, you'd split your runmodes up across many packages. You might have your content package, your shopping cart package, your user maintenance package. So really, there shouldn't be too much contention for the application files among your developers.

your main business logic (model) can be in separate modules/packages to your rum modes (controller)

I've tended to think of the model as business objects, and the run modes as business logic. If I want to change the way the application flows, I change the logic in my run modes (business logic). If I want to change the people, places, and things in my app act I change the model (business objects).

I guess it comes down to how you conceptualise things in your application environment. I tend to think as model as both business object (e.g. customer) and the rules and interactions that the object can undertake (kind of analogous to a programming object being both the data and the methods for manuipulating the data).

In my run modes, I either simply pass user input to the model package (after validating with the ValidateRM plugin), or I generate the output using HTML::Template. I used to have a bit more logic in my runmodes, but I've found that keeping them minimalistic and moving everything involving db access or business rules to other packages has made things leaner and easier to maintain

However, my apps don't tend to have complex application flows (e.g. you enter content or you update content), so maybe the logic/object separation works well for you. Anyway, I believe the MVC definitions aren't especially rigid - but some people tend to take religious positions defending their particular framework/point-of-view, but I don't find that particularly useful

• Superclass (rarely modified)
  • Utilizes classes for:
    • authorization/authentication
    • templating
    • site customization (in our case, different sites may need slightly different sitewide behaviour; we handle this through a plugin system)
  • Inherited by Application Class: calls:
    • API class(es) (for business logic)
    • Form handling class (for form validation and error handling) -- if necessary
      • Utilizes a config file
    • templates

Additionally, as perrin noted, if you're using a source code versioning system, you really should have few if any conflicts when working on the same application class. If each person were working on a single run mode, any commits to the tree could be easily merged with earlier commits as they would not be touching the same code -- each person would be working on separate methods of the class.

On the subject of APIs, I find that I typically like to write them such that I can pass some minimal information from my controller (application class) to the API, receive some data, and then pipe it into a template. If done correctly, this amounts to about two lines of code in the application class -- which makes the application class very easy to follow.

On the subject of application classes, remember the rule of thumb: if you get more than 7 run modes going in your application, you probably need to start thinking of dividing your application into multiple applications. When you get that many run modes, the class gets unwieldy to debug and maintain. This is particularly true in team environments -- any one of you may need to maintain the class in the future, and if it's too difficult to follow, nightmares, castigation, and finger pointing start to ensue.

A CGI::Application is, as you note, a controller. It's intended to determine the page flow of an application. As such, I find that if my APIs and superclass are well written, a good, clean application class ends up being incredibly sparse, and more like an outline of what happens when. You then go into the called classes and methods to determine the details.

So, in summary: your team will have a plentiful division of labor with a good CGI::Application framework.

If you're not already using version control, have a look at subversion. It's the bomb.

I want to thank everyone for their comments ... much appreciated. I wrote my first C::A this week and am very happy with the structure and flow.

author => jeyroz