active-pattern

One way to learn about programming is to actually, well, program.

I've been thinking about the Active Record pattern for a while, and how different it is from the three-tier architectures I'm used to. Both the traditional Entity/DAO layering pattern and the API (since you're calling persistence methods outside DAO's) are quite different. Views seem to vary on what Active Record actually is, as Martin Fowler's original description has it bundling data and behaviour, while Bob Martin limits it to pure data structures.

Brief looks at Ruby on Rails piqued my interest. Then, a tiny (semi-finished) utility webapp I wrote on Google App Engine for my girlfriend gave me a first practical taste of Active Record (and of what an environment with out-of-the-box full-stack integration feels like). Currently, I'm writing a small in-house web framework on top of Struts 1 for a client, and I get the feeling that Active Record could be a good way of turning it into a full-stack environment.

I'm aiming, first, for a very simple usecase to get a feel for the pattern: how it affects the overall design, the ORM challenges and integration with existing frameworks, effect on amount of boilerplate, etc. Later, maybe it could grow into something usable by a real-world, basic CRUDing app.

Some of my initial assumptions:

• ActiveRecords are actually delegating to a DAO-like Repository. This Repository is injected into ActiveRecord instances (dependency injection is handled by Guice)
• ActiveRecords mirror DB records exactly, except that foreign keys become object references
• This whole thing is pointless if it doesn't remove a lot of tedious DAO-related boilerplate
• It must be kept simple
  

With that, I give you the barely-born active-pattern.