Learning Flex Part 2: Why Service Layers Rule

In my first entry on the process of learning Flex, I mentioned that my primary learning device is my Bookstore sample application. I used this application as the basis for my talk at the ColdFusion Frameworks conference earlier this year. In that talk, I showed how building a framework-neutral model layer makes your programming life a lot easier. To illustrate why, I used a single Model, running ColdSpring and Reactor, to interact with a Fusebox 5, a Model-Glue:Unity, and a Mach-II application. The key to making this work is a well defined service layer, because it acts as a neutral API to your model that anything can use.

Well, the benefits of a good service layer were hammered home again when I started work on creating a Flex version of my Bookstore. As a result of having a neutral API into my model, I was able to reuse the same model again to feed data to my Flex application with only minor additions:

  • Creation of some simple Value Objects which can be automatically mapped to ActionScript classes on the Flex side. This was about 10 minutes of work.
  • Creation of a ColdSpring AOP advice that will translate queries into arrays of Value Objects. This was about 30 minutes of work.

Yes, as you might have anticipated, this is where I praise ColdSpring yet again. Not only will it automatically generate remote proxy CFCs for my services, but with a little AOP magic it will translate things into the format that works best with Flex. I could have let it just send raw queries out to the Flex UI, but I don't like arrays of untyped objects coming into the Flex app. I much prefer to have actual ActionScript classes that I can use as I see fit. And, yes, it was for the learning experience too. I'll probably create a separate entry to talk about (and ask for advice on) when it's best to just send a query to Flex vs. when to send an array of Value Objects.

In any event, this brings me back to the point of the article: Service layers rule. Maybe it's just me (and quite possibly it is), but there was just something really cool about being able to slap a Flex application on top of my existing model and have the whole thing JUST WORK with just a few minutes of additional coding.

Active Record Pattern Has No Consequences?

I've been looking at Rails lately, partly to see what the hype is about and partly to see what useful elements can carry over into my ColdFusion development. One of the things that I have pretty deep concerns over is its focus on the Active Record pattern. Most books and tutorials go so far as to recommend building your database first and then working backwards from that!

It would be interesting to have a discussion on whether it is a bad idea (and I think it is) to work backwards from a relational database model and hammer this down on top of your domain model. But I don't want to go there just yet. What I wanted to talk about is the Active Record design pattern itself.

Active Record (or ActiveRecord if you prefer) underpins almost everything you will see about Rails. It is the reason why "the database comes first" for most Rails folks. And I won't argue that it seems to have some nice advantages. It handles relationships and SQL and all that boring database stuff. It makes things like scaffolding not only possible, but fairly simple. Because a lot of web applications ARE actually just CRUD front ends for database data, Active Record might often be just the ticket.

However, Active Record is supposed to be a design pattern. So why it that if I Google for "'Active Record Pattern' Consequences", I get only 33 results? 33! Where a search for "Active Record Pattern" alone brings back ten thousand?

Design Patterns are supposed to be defined in a very specific way. One of the parts of that definition is to describe the consequences. These are the drawbacks or implications of using that pattern. I'm not sure why, but for some reason no one seems to be considering the consequences of the Active Record pattern. In fact, even of the 33 results I could find, none of them actually discuss the consequences of the pattern. They just happen to be results where the word "consequences" happened to be somewhere on the page. I could not find a single pattern definition for Active Record that actually discussed the consequences (or most of the other established elements that should be present when defining a pattern).

First, does someone know if I am missing something? Is there some reason why no one would be considering the consequences of this hugely popular pattern? The cynic in me almost wants to think that someone (I believe it was Fowler, who I admire greatly) came up with this idea, and then a lot of other people just grabbed it and ran with it, slavishly applying it without really giving it any more thought. Does anyone have any ideas on this? Why is Active Record, as far as I can tell, such a popular "pattern" that actually doesn't seem to have a real pattern definition?

BlogCFC was created by Raymond Camden. This blog is running version 5.9. Contact Blog Owner