ColdFusion ORM Book

OOP Terminology : Part VIII - Service Layer

So just what is this Service layer anyway?

First let's have a look at what layers we have in a sample MVC (Model, View, Controller) ColdFusion application.

MVC layers

The view layer is what we deliver to the client, traditionally this is as HTML, but increasingly this could be for Flex, AJAX, RSS readers etc. All it should be concerned with is just displaying data.

The control layer is where all your requests from the client are routed. Think of it as a parking attendant at a big event who tells you where to park your car. It determines which scripts are executed and in what order.

OK, we've now got to the model, this is where all of your business logic, the core part of your application (unless you're a designer in which case it just does magical stuff).

Inside our model we have the service layer which handles communication (message passing in OO terms) between the control layer and the Business objects. The service objects inside the service layer can communicate with your persistence layer (DAO/Gateway/Other), Business Objects and even other service objects. Each service object acts as the façade (think API) for my model. So if a controller needs to get some data it talks to a Service Object which then talks to the appropriate object(s). The same applies when the controller wants to supply some data (a form is submitted).

You may be thinking, "why don't I just combine my service layer with my control layer?". Well, you could, but this is not considered to be a good idea as you are tightly integrating your framework to your model. Imagine the issues if you might wanted to change your framework (Fusebox to Mach-II) or maybe add a flex front end as well as an HTML front end.

A question I've heard a lot recently is "Should my bean be able to save itself?" The general consensus in the ColdFusion community is no, that should be the job of your Persistence objects (DAO/Gateway/Other). However, there is no law stating that you can't have CRUD (Create, Read, Update, Delete) methods in your bean. You could even abstract the CRUD methods out and have your bean call your abstracted CRUD methods. As always with these things... it depends!

I'm sorry that I can't show you "one true way". Every technique has it's pros and cons, but it is important not to think to you must have a Bean, BeanService, BeanDAO and BeanGateway. This is a common approach in the ColdFusion community, and has a lot going for it, but it is not the only one. Hopefully I've got you thinking about how you want your applications to be constructed to suit your needs, rather than just doing what seems to be the right way.



  1. I have a couple thoughts on Service layers that I would like to throw out there. First off there are instances where a Service layer (an api to your model) works but I would say for the most part they are a waste of my time. There is no reason to create service layers for every object in your model.

    To your point of what happens when you change frameworks or views. If these are issues that others are having than fine but I rarely come across this. I never write an app in ModelGlue and decide let me change to Mach-ii. I just think the overhead of service layer architecture is too much and they should be thought of on instance basis only.

    Love to hear what others think.

    Comment by Dan Vega – October 17, 2008
  2. @Dan, always good to have your feedback. I agree that the chances of changing your framework, database server or xyz is unlikely. The YAGNI principle ('t_Gonna_Need_It) is a good one to bear in mind when building applications, but it shouldn't stop you also thinking about aspects of good architecture. However, I have run into the issue where I needed to get data for AJAX calls.

    I try hard not to push one pattern over another in my posts, I just want people to take the blinkers off, have a look around, if they then decide to do it the way that they always have that's fine with me :)

    Comment by John Whish – October 17, 2008
  3. @Dan,

    So far, I am really liking the Service layer. But, keep in mind that I do not use a Gateway or DAO. So, for me, the persistence and the queries are all done in the service object.

    I think we might agree that having that 5-to-1 (5 objects per entity) scenario is no good, but I use the Service to concentrate functionality where others might use a Gateway. That might just be a personal choice.

    Comment by Ben Nadel – October 18, 2008
  4. @Ben, with you all the way about the 5-to-1 thing! when I first started looking into OO I thought that 5-to-1 was the only way. It really put me off and I actually gave up learning OO for a while because of it!

    Comment by John Whish – October 18, 2008
  5. Personally I view design patterns (service layer, gateway, etc...) and OO as separate things.

    OO is just a bunch of fundamental concepts (classes, objects, properties, methods, inheritance, abstraction, decoupling, etc...).

    Design patterns are options you can choose as part of your software architecture.

    Techies dream of code purity. But from a business perspective you need to weight the cost/benefit of all the upfront work of potentially over-engineering your solution for a crazy level of decoupling.

    Sure, theoretically it can save you time in the long run if you're making changes at certain layers. But if it costs you more in upfront development that you're never able to recuperate in reduced maintenance time - then the extra work cost unnecessarily more. From a business perspective, development time is EXTREMELY costly.

    So, if you're concentrating a lot of logic into a service layer (vs. what might have gone into a gateway), and you're able to support enhancements within a reasonable timeframe - then mission accomplished!

    Comment by Darth Sidious – October 29, 2008
  6. @Darth, thanks for taking time out from building the empire. I agree with everything you say (does that mean I've joined the darkside?) As I said in the post every technique has it's pros and cons and there is not one true way.

    Comment by John Whish – October 30, 2008
  7. @John: Welcome to the Dark Side! You see... rebel scum fantasize about utopia. This theoretical goal of TOTAL abstraction, TOTAL decoupling, TOTAL configuration driven business rules/events/workflow.

    As valiant as it is... what's the cost to the business? Have you seen how ghetto the rebel spaceships are vs. our Star Destroyers and Imperial Cruisers (which by the way are proud to brew Starbucks coffee in the break areas).

    Time to market is key, and I'm fine with cutting back on some utopia and theory in order to get things done fast.

    Comment by Darth Sidious – November 04, 2008
  8. @Darth, knowledge is the true force! Not just technical knowledge, but also the knowledge you gain from experience of when to use what.

    As for Starbucks, without starting an intergalactic incident - some would say that they are akin to The Borg. You will be assimilated!

    Comment by John Whish – November 07, 2008
  9. @John: Yes, oddly enough the Empire does have a strategic partnership with the Borg. Though don't tell them I said this, but between you and me I view them as annoying pests. So to keep them busy we've let them do whatever they want within the UFP-United Federation of Planets (from Earth/Klingon territory up to and including Deep Space 9).

    We've genetically engineered a virus that easily wipes them out... But they come in handy in keeping the UFP busy, otherwise they could potentially team up with Rebel scum and cause us a lot of grief.

    Comment by Darth Sidious – November 08, 2008

Leave a comment

If you found this post useful, interesting or just plain wrong, let me know - I like feedback :)

Please note: If you haven't commented before, then your comments will be moderated before they are displayed.

Please subscribe me to any further comments


Wish List

Found something helpful & want to say ’thanks‘? Then visit my Amazon Wish List :)


Recent Posts