NO MORE CAREER
POLITICIANS!
Get Out Of Our House: Replacing congress with TRUE citizens!
Contact Doug!
Learn About Doug!
View Doug Boude's online resume
updated 11/18/2009

View Doug Boude's profile on LinkedIn
Link to me!

Follow Doug Boude on Twitter
Follow me!

Be Doug's friend on Facebook
Befriend me!
(I promise not to follow you home)
OO Lexicon
Chat with Doug!
Recent Entries
You may also be interested in...
Web Hosting

best web hosting - top web hosting sites, thetop10bestwebhosting.com

Czech your Page Rank!
Check Page Rank of any web site pages instantly:
This free page rank checking tool is powered by Page Rank Checker service
Surf's Up!
Visit Egosurf.org and massage YOUR web ego!
My Score: 9,001
Doug's Books

Read (and recommend)

  • Men are from Mars, Women are from Venus
  • The Wisdom of Crowds: Why the Many Are Smarter Than the Few and How Collective Wisdom Shapes Business, Economies, Societies and Nations
  • Blink: The Power of Thinking Without Thinking
  • Head First Design Patterns
  • Transact-SQL Programming
  • What's So Amazing About Grace?
  • Just So Stories (Rudyard Kipling collection)

Reading

  • Prayer: Does it Make Any Difference?
  • Data Mining (Practical Machine Learning Tools and Techniques)
<< September, 2010 >>
SMTWTFS
1234
567891011
12131415161718
19202122232425
2627282930
Search Blog

Recent Comments
Re: Railo 3.1 on Windows Server 2008 and IIS7 - Part 3 of 3 (by Jon at 8/27 2:04 PM)
Re: Hosts File Changes Not Acknowledged on Vista 64 (by Spacy at 8/24 3:46 PM)
Re: THE DAY CFUNITED DIED (by ComboFusion at 8/23 10:50 AM)
Re: My Grandpa (by Tasha at 8/10 4:29 PM)
Re: Just What IS a 'Service Layer', Anyway? (by dougboude at 8/02 10:10 AM)
Re: Just What IS a 'Service Layer', Anyway? (by Isaac at 8/02 2:25 AM)
Re: PayPal IPN Coldfusion CFC (by Soyestudiambre at 7/25 6:12 PM)
Re: PHP vs COLDFUSION (by Tony Garcia at 7/17 11:24 AM)
Re: PHP vs COLDFUSION (by dougboude at 7/14 8:45 AM)
Re: PHP vs COLDFUSION (by Lola LB at 7/14 5:51 AM)
Categories
Archives
Photo Albums
Funnies (5)
Family (3)
RSS

Powered by
BlogCFM v1.11

21 February 2007
Just What IS a 'Service Layer', Anyway?

(Consider hiring Doug to instruct you and your team in the ways of OO!)

I've been hearing the term 'Service Layer' everywhere for at least the past year and a half, as I'm sure most of my peers have as well. Whether it's seen in blog posts, heard during casual conversation at conferences, found in articles, or woven throughout almost any discussion at all concerning OO and Coldfusion...the term is quite prevalent and common these days. But I had a problem: the term held absolutely ZERO connotation in my mind. No picture was ever conjured up when I came across it, no corresponding 'Doug Boude' translation was found in my internal lexicon; I felt quite out of the loop. Ah, but recently that has all changed, as the phrase itself has not only come to life for me, but found an absolute and permanent place in all that I do, technically speaking; an epiphany, if you will.  I just figured there were others out there who, like myself, may still be kinda grasping for a way to think about the term, so what follows is my personal definition/explanation of what a Service Layer really is. Please feel free to append, addend, flip, and twist it to your heart's content until it's as whole as it ever can be.

SERVICE LAYER

 

 

This is not NEARLY as gray and ambiguous a term as you might think. Picture if you will, a man sitting comfortably on his sofa. In one hand is the remote for his very large plasma TV; in the other hand is a remote for his home theater system. The two remotes and the man are all objects, and all three come pre-built with things they can do. In the kitchen is the man’s wife; let’s think of her as the calling application. She barks out the order to the husband object, “START THE MOVIE, YOU IMBECILE!”. The husband object just happens to have a startTheMovie method, and begins to execute it. First, he manipulates the objTVRemote object, calling its “tvOn” method. Then, he manipulates the objDVDRemote object, calling it’s “dvdOn” and “dvdPlay” methods. Now he manipulates the objTVRemote again, calling the “inputSRC” method and switching the tv to receive the dvd input. Tada! Movie is playing now!

Pretty clear scenario, eh? Well, in this illustration, the MAN is acting as the SERVICE LAYER. Although he has a “startTheMovie” method, all he’s really doing is coordinating efforts between other lower level objects that actually do the work. His wife doesn’t care about the remotes or how they work, and her life is then simplified because she need only make her one call to her SERVICE LAYER OBJECT and he handles the nitty gritty details. Service Layer…not such a deep, complicated mystery after all, is it?

Doug out.




Posted by dougboude at 6:15 AM | PRINT THIS POST! |Link | 13 comments
Subscription Options

You are not logged in, so your subscription status for this entry is unknown. You can login or register here.

Re: Just What IS a 'Service Layer', Anyway?
Yeah, I've always fantasized about a Service layer that the ColdFusion developers would call.
Them: "SELECT * FROM Cust".
Me: You may WANT a list of all customers, but this is the list that I'm going to GIVE you:
SELECT * FROM Cust
INNER JOIN Security
ON Security.CustID=Cust.CustID
WHERE UsrID=#You#
Posted by Phillip Senn on February 21, 2007 at 11:06 AM

Re: Just What IS a 'Service Layer', Anyway?
Great analogy!
Posted by Sal on February 28, 2007 at 11:06 AM

Re: Just What IS a 'Service Layer', Anyway?
Is this the same as an Object Factory?
Posted by Josen Ruiseco on March 2, 2007 at 3:40 PM

Re: Just What IS a 'Service Layer', Anyway?
Hi Josen!
Actually, no, a service layer is not an object factory at all...two different animals. An object factory is itself and object whose job it is to create instances of other objects for you. So, instead of writing 'createObject("component","model.user")', you'd instead ask your object factory for it with something like 'cfset myNewUserObj = objFactory(objToMake="user") . Make sense?

Why would you want to do this, you might ask? Well, you might want to do this in order to simplify your object creation process and lessen the amount of code needed throughout the rest of your app. There are a myriad of other possible reasons to do it, as well, but that's content for a blog post all its own.
Hope this helps some.
Posted by dougboude on March 2, 2007 at 3:59 PM

Re: Just What IS a 'Service Layer', Anyway?
I get it now...another debate that I have heard is where the business logic should reside...in the service layer or the domain objects. Can anyone expand on scenario?
Posted by arcot on March 17, 2007 at 10:57 AM

Re: Just What IS a 'Service Layer', Anyway?
Ah, you've used yet another commonly used term ("domain"), yet one which tends to conjure up very little by way of visual associations. As far as I'm concerned, and the team I work with, the "domain" of any of our applications is everything that lives inside and under our "MODEL" directory. Our rule of thumb is (and we've adopted and modified this to meet our needs) that, if we had to change frameworks tomorrow, everything that IS our app should live inside the Model directory, INCLUDING and ESPECIALLY the service layer objects! Here's a scenario that REALLY drives this point home:
We build an app that manages medical benefits. In order to perform a simple task such as "change my medical coverage", there are actually several underlying object calls needed, and thus a "benefitServiceLayer" object. Now our home office mentions during a status meeting that they'd like to be able to leverage that same business logic in an app they're building, and they'd like to do it via web services. The only object that needs exposing as a web service is our benefitServiceLayer object...all of the other objects live below that one and are not accessed directly from the home office. So, from this scenario, it's absolutely clear that our service layer objects are JUST as much a part of our 'domain' as any other object containing business logic, and thus the service layer objects must belong within our MODEL directory.
That's what it looks like from where I'm standing, anyway.
Posted by dougboude on March 17, 2007 at 11:11 AM

Re: Just What IS a 'Service Layer', Anyway?
Thanks for this excellent and humorous explanation of "service layer."
Posted by Keith DeWeese on July 4, 2008 at 9:07 AM

Re: Just What IS a 'Service Layer', Anyway?
Now I'm confused. I thought the controller was making these calls to the the models involved. Am I just smoking something?
Posted by toddk on April 1, 2010 at 5:44 PM

Re: Just What IS a 'Service Layer', Anyway?
Todd - I ask myself the same question - isn't the service layer just replacing the controller? In a lot of simple web apps, I believe the answer is yes. For example, in my "Edit profile" page I pass all of the form data to my "User" object and save it - pretty simple. But what about something like saving the user's new avatar image? Should image manipulation code go in the model? Should code deciding on where to store that image go in the model? Opinion generally says no to these questions. So it's down to the controller to save the resize and save the image then? Well, yeah, why not! If all of a sudden you find yourself repeating this code because you're creating for example a SOAP api for your users then maybe it's time to look at a service layer (which could just be a "UserService" class).

There might be people who say that the service layer should be created from the start, and I wouldn't have a solid argument against that except that it's creating more work than necessary to get your code out of the door.

I'm done rambling now.
Posted by James Thomson on April 6, 2010 at 6:14 PM

Re: Just What IS a 'Service Layer', Anyway?
@Todd and @James - Here's my two cents, which as James observed, is strictly opinion based on what jives best with the way that I think.

In essence, the controller's job is strictly to act as liaison between view templates and the model. The model is where all the action is; the business rules, db access...everything! As a courier, or liaison, the controller then should have his job kept as simple as possible. Some people call this "keeping your controller thin", etc. But what it means to me is that when I'm writing a controller, my goal is always to have it do as LITTLE as possible...basically doing nothing more than receiving incoming values, perhaps doing a little "fix up" on them, passing them in to the model, and then taking whatever the model returns and putting it where the views can get to it.

Now, down in the model, where all the action is...that's where the service layer objects reside. Their duties tend to be more complex than other model objects, performing actions that require a little more "thinking", broader reaching methods, and (this is the key for me) the manipulation of other model objects. Anytime I find myself writing a method that needs to talk to, manipulate, or otherwise access other model objects, that CFC becomes a candidate as a service layer object. Not all model objects who interact with other model objects are service layer objects, but I would say the majority are. It really comes down to what kind of role the object plays as to whether or not it rises up as a service layer object.

Back to the controller and its job, though, my strict opinion is that when I look at the code a controller is executing, it should be EXTREMELY simple and "thin". If you had to change frameworks tomorrow and all you were allowed to take with you was your model...would you find yourself having to rewrite a lot of code? If so, you may want to consider thinning out your controllers.
Posted by dougboude on April 7, 2010 at 9:25 AM

Re: Just What IS a 'Service Layer', Anyway?
@doug - your point about having rewrite code if you don't use a service layer certainly made me think. I have to admit that sometimes I focus perhaps a little too much on the application I'm working on at the time when I should give a little more thought to the re-use of the models in the future. Cheers for an excellent article btw!
Posted by James Thomson on April 7, 2010 at 1:15 PM

Re: Just What IS a 'Service Layer', Anyway?
Doug, thanks so much for this post. I'm trying to wrap my head around service layers and this was definitely an instructive and high-larious analogy.

It seems like a service object method should coordinate 1 or more domain object's activities (Husband::turnOnTv() = Tv::on() + SurroundSound::on() + Remove::switch()), and at the same time provide the application layer with a well-defined list of things it can do with/to the model. I'm curious to know where fairly simple single object actions, like updating a domain object's properties, or deleting a domain object, would fit.

For instance, let’s say for your user object there are effectively three kinds of properties: personal information (name, email address, nickname, and favorite animal), password, and preferences. Would the User Service object implement upatePersonal, updatePassword, and upatePreferences methods, and the controller would take the client's input and pass it along to the service layer methods? Or would the User Service object implement an "updateProperties" method, and the controller would effectively "decide" what properties to pass it? Is the answer "either is OK, as long it's in your User Service object, and the choice depends on how you want to draw your applications boundaries?"

Many thanks in advance for any advice.
Posted by Isaac on August 2, 2010 at 2:25 AM

Re: Just What IS a 'Service Layer', Anyway?
@Isaac, glad my analogy helped! As far as the scenario you laid out, one thing to always make a hard and fast rule is that NO business logic belongs in your controller, ever. If your controller is having to make more than just small, menial decisions, then that code probably belongs in your service object. As far as what methods your service object would/should have in your scenario, what I do is think about what the API is going to look like from my application's point of view. Is it more intuitive to have a method called "updateProperties" that I call anytime I have any properties to update, or is it more intuitive and easier to read my code later if I am calling methods whose names indicate a more specific kind of action, like "updateUser"? My own preference would be the latter, and that one method would accept any of the user object's properties (password, birthday, lastname, etc.). Like you said, though, it really comes down to how you prefer to draw your app's boundaries, or what API makes the most sense to whoever is going to be using it. Not really a right and wrong there, for the most part; just go with what makes sense to you! :)
Posted by dougboude on August 2, 2010 at 10:10 AM

Name:   Required
Email:   Required your email address will not be publicly displayed.

Want to receive notifications when new comments are added? Login/Register for an account.

Time to take the Turing Test!!!

1 plus 5 equals
Type in the answer to the question you see above:

Your comment:

Sorry, no HTML allowed!