I am a huge fan of compact libraries, like JUnit or XStream, that concentrate on a very concrete problem and offer a very concise and elegant solution. It seems like frameworks are rarely approached that way. Of course, the scope of the problems frameworks, as opposed to libraries, address is vastly larger - I certainly would not expect an API limited to five methods from Hibernate… - but that doesn’t mean it should always be that way.

Another reason I favor the Library over the Framework approach is that libraries do not impose a certain style of programming to the developer. Promoting good practices is certainly desirable, but lest we forget it is often to the expense of flexibility and creativity if not handled with care.

The Model is undeniably the heart of an MVC application. Different applications rarely have to capture the design of the same Domain. Even when the Domains are similar, it is, again, rare that similar approaches would best fit their respective development. This is why I think the Model, in its pure form, does not, most of the time, benefit from structural guidelines imposed by frameworks.

I hold some reservation against the currently popular approach of tying an application’s Model with the Persistence Tier. Persistence, for the most part, is a static representation of an application’s Model. The same way an HTML view is but a visual representation or means of an interface to it. The Model itself, on the other hand, is volatile and dynamic. It is supposed to change and respond to change. And varies immensely between different Domains. Developers have gone to great extends in order to decouple the data from the application code. I don’t see why the relationship between Model and Persistence should not be likewise approached.

The Controller on the other hand is presented as a rather confined problem. Make that a web application’s Controller, and since the HTTP protocol is so strictly defined, the problem is not even that difficult to solve.

Aerie focuses on solving this exact problem in a as least-intrusive and as consistent as possible manner. The way it is meant to be used is as a very thin layer between a Web View and the Service Interfaces that sit in front of a web application’s Model. It is meant to be an easy and concrete solution to an easy problem, so the bulk of the developer’s efforts can be dedicated to the part that deserves it the most: The Model.

Aerie is MVC without without the M in that it does not involve the Model tier of the Model-View-Controller paradigm.

The aim of Aerie is to simplify and standardize the Controller and View aspects of Java web application development.

We recently set up Aerie’s new home on Google Code.

Thanks for giving Aerie a spin. It’s really easy to setup and get started with. You can download it here and read the - incomplete (working on it…) - user guide.

Please keep in mind that these are early steps in Aerie’s life, so expect it to be a bit rough around the edges.

Thanks for dropping aerie [at] nutrun.com a line with what you like or don’t about Aerie.

Download Aerie

Aerie User Guide

Aerie Feed