The Service Layer
Web Development
Lately I have read a few blog posts and talked to a few developers that either disagree with or are unfamiliar with the reasons for using a service layer in web applications. After posting this as a comment on the great Peter Bell's blog , where he references the discussion, I realized I might be better off cleaning it up and posting it here. While I don't go into detail about how I use service objects, I will save that for a later post if anyone says they are interested.
What I usually do is create a service layer for all gateways, DAOs and many other types of handlers including an email service that can prioritize outbound emails in an email queue. Some may argue that I even overuse the service pattern, but in all truth, I think it is very underused in web applications.
These are my explanations of why I feel the service layer can be a great benefit to both the developer and the resulting application (in terms of performance and stability).
The Developer
Having services is often the more logical way for a programmer to think...It often puts things in a very real world perspective. For instance, why do i see so many implementations of a shopping cart that not only contain items, but calculate all the invoice totals, manage taxes, shipping, etc. Doesn't it seem a little more logical to take the cart, along with coupons, etc. to a single register (similar to what you would do in real life)? I find it very easy to deal with a large set of requirements this way (no memorizing URL diagrams or looking at classes with 400 functions). With DAOs and gateways for a typical bean I like having the service layer to say, "Hey, go put this thing in storage for me" which could be totally different places (database, xml, etc.) any time I use the same bean. On the other hand, I can enjoy the active record type pattern by using ColdSpring to pass my beans a dao and give them an incredibly simple save method.
The Application
The application becomes incredibly solid with the use of the service layer...I love knowing that my application loads and 90% of the memory it will ever use is set and ready to go (and it is much smaller than reinstantiating a bunch of large objects on every request). My applications rarely bounce up and down by massive percentages of processor and memory usage because a few more or less users are on. It becomes very easy to spot when something is awry because I know what to expect. Alternatively, with tools like Spring, ColdSpring, etc. I can load objects every time, or as a singleton when first needed, or anyway I like with a few keystrokes.
Conclusions
I think sometimes we get a little too radical for our own good. It seems fairly often lately that I run into "Why the heck do we need X debates?" that claim much less complexity, removing item X allows the developer more creativity, and the application more flexibility. While I think these debates are healthy, I try to remember one thing...programming is about us...if it wasn't, then why didn't someone just come up with a cross-platform assembly language so we could stop there. The service layer is a tool for making things easier for us to understand and manage...it is also incredibly flexible.
My reading lately brought me to asking myself:
How much more work is it to have a service object than to embed this into my objects as they are?
Is adding more types by having a bean and DAO singleton over complicating something?
I've come to the conclusion that the difference if there is one is probably within minutes of eachother, and I could see the service layer even winning out quite often only because I think it is often "more human" for the developer to think of many problems that way. Does every customer get a cash register at a store? Do we all have our very own post office? Makes it very easy to have a flexible application and not have to memorize a complicated UML diagram in my head at least. That answers both questions for me at least.
It is easy for us to use tools like the service layer in dynamic languages and we deserve that benefit for as little work as it is now to implement. That being said, if you don't think its the right tool for the job, don't use it...we all have paid the price for using the wrong tool before and we learn from those experiences differently.
Mike.
What I was hoping for from my posting was a comment from someone with experience in writing large apps without a Service layer who'd tried both approaches and on balance found getting rid of the service layer to provide substantial benefits that neither you, Cliff nor I are "getting" right now.
I'll certainly let you know if I find anything out, and please drop me a line or a comment if you find out what we're all missing.
By assuming we're missing something we are always open to better approaches when they come along - even if they aren't explained very well to start with (which is usually the case) so we're more likely to be able to take advantage of new advances when they appear. And if it turns out that we AREN'T missing something, I don't think we really lose very much. At least in the spirit of Edison we've found another way NOT to architect an application!
I will definitely be watching for anyone to flesh out their words further on this issue and will learn something from it for sure.
Thanks for keeping us all asking questions about ourselves as well as the practices of others.
Mike.
Loading....