Ogres Have Layers… Onions Have Layers…

I apologize for the obscure Shreck reference but that scene from the movie pops into my head every-time I start thinking about all of the different layers we code into our applications. I was thinking recently about how many different layers we use and I started to wonder, are we doing this because it truly makes our applications better or simply because we can?

As ColdFusion has progressed as a language, lots of these concepts have started to surface from other types of programming. Seven years ago, no-one was talking about building service layers and domain models in the ColdFusion community, we were so focused on frameworks and trying to increase code re-use. Now its not uncommon for an application to use a framework and MVC to separate the views from the model and use a controller to tie it all together, then throw in a service layer as your model which points to a data access layer and processing logic layer and, well you get the point.I see the benefits of having layers within your application, dont get me wrong, but sometimes I feel like maybe we over do it. For instance, when I write Fusebox applications, I use MVC patterns and write all of my controllers in XML like a good little Fuseboxer, I use a custom lexicon to call my ColdSpring factory and get beans in those controllers which call my service layer objects. Now these service layer objects do not call the database directly, they call methods in the data access layer to actually handle that. My biggest question is why does the controller have to call a service layer when it can interact with the data access layer directly. cant the controller act as a service layer? Are there any benefits of using the service layer that outweigh all of the extra code in the layer that has to be maintained?

Now I know that there are no hard and fast rules when it comes to architecture. We are free to do things as we chose. I guess Im just playing devils advocate here more than anything really. Sometimes when we look at things in a totally different light, they become more clear.

7 thoughts on “Ogres Have Layers… Onions Have Layers…”

  1. service layers are a must! (imo). Why? because it abstracts you that much more in your development code. What the hell does that mean? Say you wrote out your model and stuff and your adhereing to MVC and such…blah blah, and then you wire everything up in your controller and your done right? but wait! what if suddenly you have a reason to move from fusebox to model-glue? what will you do? well, you would go and copy/paste your controller code into the model.rr..wait, fusebox uses an XML file! Crap! and suddenly you find yourself re-writing alot of higher-level code that could be what comprises your service layer!

    A controller and a service layer can often times be thought of as one in the same, but making that extension to the service layer is only a plus because it makes your code less reliant on the frameworks methodologies but still allows you to fully utilize it (ie: conditional logic, etc.)

    AND even still…what if you want to utilize something like flex? your codebase won’t have a port for flex to communicate with (since it was originally your controller).

    just my 2 cents, I think you can never go wrong with implementing a service layer.

  2. Derek,

    Allow me to play devils advocate again for a moment. One thing that I hear alot of is we do things this way because if we ever want to change the whole application over to a new database, or we do things that way because it will make it easier to move the application from this framework to that framework. I hear it all the time, But I remember Nat Papavich saying in a meeting one time, "everyone talks about that, but noone ever does it".

    And I agree with him, at least in my experience. I have been developing ColdFusion applications for 10 years now and I have NEVER or had the need to change out a database engine or move an application to another framework for any reason other than just research or learnings sake. So that makes me wonder… are we going that extra few steps just to give us the peace of mind that we could do it if we wanted to?

    Again, just playing devils advocate.

  3. Russ,

    Unfortunately, I wish we were doing it for just the piece of mind. My last employer could have benefited from this extra abstraction when he discovered one of our clients wanted to switch from MySQL to MSSQL. This task was basically impossible, yet if we had used something like Transfer or Reactor to handle the database model…it’d be no problem! I don’t think that many people go around swapping out fusebox or model-glue on a regular basis, true…but if nothing else the whole point of multi-purpose model via service layer is a huge benefit (especially in the flex world).

  4. I think that with any framework you should keep your model (or service layer if you will ) very independent and not based on the framework. This allows you to re implement as you like. Its as simple as that and the reason that MVC is a popular pattern in the web dev world.

  5. I was troubled by the same question when I first forced myself to use Fusebox (2 at the time) and has bothered me with each new layer I’ve added since. The answers about changing databases/frameworks are valid, but too specific. The more layers you have in your app, the better prepared it is for *any* kind of change. Why? One word: Isolation. Whenever you change any bit of code you have to think through how it might affect other parts of the app. Dividing up your app into isolated layers that only do limited things and are only connected in limited ways means that a change to code in one layer is far less likely to affect code in another layer.

    So while you’re not likely to change from Oracle to MySQL very often, or from Fusebox to Model-Glue, what about changing a variable from session to request scope or vice versa? My DAOs and Gateways know nothing about sessions or requests so I can safely ignore that whole portion of my app when making the change. Less worry, less work. More robust, more flexible.

  6. Don’t forget, too, that it’s not always just about refactoring a particular app. Writing portable code benefits you in being able to write future apps that can more easily integrate with existing apps when they’re written correctly up front. And maybe chunks of your code, being so portable and agnostic, will be usable in another app that, oh yeah, just so happens to be in another framework. And so on. After 7 years, I’ve found that doing things right just always makes things easier down the road, in one way or another.

    Another case in point. I am 90% done with an app that I wrote WITHOUT an ORM framework. Now at the 11th hour I’m finding some extra functionality that I need to code into my CFCs that would’ve been there automatically if I had used Reactor. Ugh.

  7. Just wanted to thank all of you for the great comments… some really good points!

    Im not going to change the way I code my applications. I will still use Service Layers and DAO’s/Gateways but it was really great hearing all of the "valid" reasons that other developers are using them as well!!

    Thanks again!

Leave a Reply

Your email address will not be published. Required fields are marked *