Myself, I would say that Mason is one way of implementing the model-view separation.

(My suspicion is that you're talking about web development frameworks based on object-relational mappers like Class::DBI, in which case, I disagree strongly with your claim that they're the right way to develop "large" projects. They may be quick, they may be fun, but scale, they do not.)

MVC is an all around more rigidly structured way of handling the web, it tends to yield better code on the whole, while being easier to divvy out amonst a team. It is more so maintainable and scalable.

You have three fine divides, a model - interacts with the database (makes the data accessible in your language of choice), a controller which can access a model and holds all of your programming logic, and a view which simply reads from the context variable - catalyst's stash, rail's flash/other misc custom globals, etc.


• More than one medium can access the model, the interface to the db in perl, Class::DBI, DBIx::Class custom DBI modules etc, in our implementation, the models are recycled and I use the same modules when inserting data with web crawlers, that i do when users add the data themselves.
• The controller is often kind of like a server side http/rpc, and can be largely reused, http://foobar.com/1/2 will in most implementations dispatch to the function '1', the arg '2', in Catalyst you can form this 10900498084 different ways, you could in the path '1/2/3/4', send the function 1, the value 2, the function 3 the value 4, etc, these functions are written in the controller logic
• view is any of the many template languages available to what ever lang you pick. TT, embperl, etc these only deal with presentation logic.

The best Mason users, found on the mailing lists, will highlight these points in their methodologies, which largely mimic MVC now too. they often put their model functions in modules, isolated from the .mas files. A dhandler in mason is easily abstracted to be a controller, and the autohandler and seamless calling chain are the powerhouse of the language. If you start doing this too, and then you pick up a true MVC framework, you might come to view Mason as less developed -- I have.



Evan Carroll
www.EvanCarroll.com

Okay, well as I suspected, we have a terminological difference going here. You talk about "using an MVC", but I think of MVC as a design pattern, not a category of software.
• MVC at Perl Design Patterns
• MVC at wikipedia
Further, it's somewhat confusing to talk about an MVC as opposed to Mason, because Mason can -- as you admit here -- be used to implement the MVC pattern. And that's pretty clearly the recommended usage in the Mason world:
• style guide at masonhq
Also, as I suspected, when you talk about "a true MVC framework", you're talking about the current fad for what I would call web application frameworks, all of which (to my knowledge) use some sort of object-relational mapper, (e.g. Class::DBI). The key feature of these things seems to be that they sacrifice database design for the sake of object design, which while this may speed up development it strikes me as being exactly backwards as far as performance is concerned.

And so we come to your closing shot: "pick up a true MVC framework, you might come to view Mason as less developed -- I have." May I inquire, in what way you find it "less developed"?

Amazon doesn't use Mason externally, they use it internally to "prototype." Many books have clairfied this.


Evan Carroll
www.EvanCarroll.com

Amazon doesn't use Mason externally, they use it internally to "prototype." Many books have clairfied this.

So it shouldn't be too hard to name one of them, right?

I can't find this anywhere on the web. As of a few years ago the story was that Amazon was using Mason quite a bit, and had plans to use it even more...

• Jonathan Schwartz
• Mason HQ
A number of sites use Mason: MasonPoweredSites