It’s what it doesn’t do
When I set out writing Aerie, I had one very clear goal in mind. I wanted the API to be so tight that it would discourage people from using it extensively. I would very much like to witness Aerie becoming useful and be used in as many applications as possible. However, I want the interface to make it clear that the Aerie part is the least likely of places where the bulk of a web app’s codebase should go.
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.