I just finished a rather interesting – one might even say rather elegant – web application that I think has a lot of future in it. I'd like to briefly describe that design here and see what you think. (Full disclosure: I'd be even more delighted if you want stuff like this and if you like telecommuters!) :-D

The app is built, as it were, on the Mojolicious framework, partly because that framework is small and mostly because this application is basically being done entirely with Moose object-oriented programming. But, one of the “rather different” attributes of this application is... “it's not all about the framework.” This application design is really, from stem to stern, all about the objects.

What Moose really gives you, really for the first time, is a first-class object structure that allows you to leverage a lot of existing (off the shelf) functionality in very creative ways. The key to this seems to be especially in its concept of Roles. For instance, the single statement: with Storage ( format => 'JSON' ); gives any object (or any descendent thereof) the instant ability to be reliably serialized and unserialized ... and you don't need to do anything particularly beyond that for “it just works.” When you combine this with other stuff like MojoX::Session, you have persistent objects without the headache.

Many web-designs seem to be very “database centered,” with the most-extreme example of course being "CRUD" designs. But really, an (SQL) database is really just another expression of “persistence.” The database is a source of information that objects may refer-to when building themselves, and it is also something that the objects may from time to time update. But it isn't the center of the application-user's world ... nor should it be the center for the designer's.

This particular application's “world” is a seminar registration system. This world therefore contains a slew of persistent, serializable objects – I call them Things – such as:   Seminar, Person, Invoice, CreditCardTransaction, Instructor, Venue, and Seat. Importantly:

• A Thing has no direct correspondence to any particular SQL table, although it may load its initial information from one or more tables, and it may likewise update them.
• Once a Thing has been instantiated, it can be serialized into the session-data (automagically!) and retrieved at any future point. (I built custom methods into the application's MojoX::Context object to easily retrieve the base Things. When one Thing refers to another, and all of them are serializable, all of them are magically serialized and restored. “It Just Works™.” Sweet! So, you're not constantly hitting the SQL database to build an object once you've already built it.
• Any suitable form-handling and HTML-templating system can be used, and since Things are well-behaved objects you can simply refer to them in your forms and templates. They work, when used that way, just as they do when accessed in any other situation. If your app uses AJAX or SOAP or what-have-you, “Things still Just Work.”
• The resulting logic is extremely orthagonal and expressive. You find yourself, a little ways down the line, asking... “is this really all I have to say here?” And the answer, in most cases, is “yes.”

I find that this application design really rattles the venerable foundation concept that we call, “MVC.” It rattles that foundation so much, in fact, that several of the letters fall off... especially “M” and “C.” Although various forms of data-model do exist, the application isn't centered around data anymore. Nor is it centered around an application-specific “controller.” My app has a number of scheduled scripts, for example, that are able to use these Things in exactly the same way as the web-app code does. The rules are not different. The web-app does have controller code which drives a particular HTML form (or subform), but those controllers (and their parent classes) are almost reduced to GUI-style “button pushers,” which of course they are.

Over the years, I have dealt with a lot of “web application code” that I really felt had zero future. (Especially a nightmarish year spent with an e-commerce company's twelve year old code ... they should have known better.) This code really seems to be different. It's loosely coupled, and I think that it will therefore continue to “have a future” for many years to come.

What do you think?