Up to this point, our application consists of two packages, one for the projects and another for the users. Both packages contain a Data Access Object, dealing with single-row data transactions; a Gateway object, dealing with multiple-record database transactions; and a Bean object, to contain and persist the informatioln where required.
Beans are transient, due in large to the fact that they are typically persisted across the entire application and can pass through all layers in the tiered architecture.
In this chapter, we will discover the power and abilities of service layers within our application. A structured application built with service objects removes any major issues with object dependency, meaning that, to an extent the objects instantiated within your application are not dependent upon having the knowledge of the inner workings of any other objects and what each one does, but instead they simply need the ability to communicate with each other to perform the actions required.
We will alter our application to no longer create the Data Access Objects or Gateway objects directly, instead choosing to use the Service Layer for direct method calls, which in turn will communicate with the DAOs and Gateways to perform the database enquiries.
We will also look into the following:
- Amending existing code to call the service layer
- Streamlining the CRUD and Gateway methods
- Object inheritance
A Service Layer is quite an easy object-oriented concept to understand.
Let's run a test scenario.
You're up late. You've been working for hours on end trying to complete some urgent coding amendments that need to be delivered to a tight deadline. You're tired, but my goodness the work is done. You're dedicated—what more can anyone ask for. Be proud.
Just as you finish the final keystroke and save the work, your stomach rumbles. You know what that means. It's time for some food, then off to bed to sleep for an eternity.
Your stomach has told you what to do with the "sleepyStomachRumble()" method. You just need to follow orders now, and you kick into auto-pilot.
First things first, time to shutdown the computer, using the "pcOff()" method. Slide yourself off from your office chair using the "deskEscape()" function, and off to the kitchen to prepare a few slices of toast; "breadIn()", "toasterOn()", and "spreadJam()" methods respectively.
After savoring your hard-earned slices of toast, it's time to turn off the lights and head to bed; "lightsOff()", "quickShower()", and "sleepLikeALog()" methods.
Mission accomplished.
A slightly bizarre situation, I grant you, but in this particular situation you are acting as a Service Layer.
You had the "sleepyStomachRumble()" method pre-built into your psyche—hours of late night development will do that to you—but that one method was coordinating other objects and their contained methods to complete the process to take you away from the desk and into the kitchen for food before whisking you away for a good night's sleep.
In essence, one method was called, an easily memorable method name, but underneath that single method runs a series of other functions to complete the task. No one needs to be exposed to the intricacies or the details. All that needs to be run is the "sleepyStomachRumble()" method.
A Service Layer forms a basic Facade Pattern for the application, and a simple interface to interact with the code base.
A Facade Pattern is a type of design pattern commonly used in object-oriented programming. The word 'facade' stems from the French language, and literally means 'frontage' or 'face', and a facade pattern is an object that provides a simplified interface to a larger body of code, such as a Class package or library.
A facade can:
- Make a component library or group of packages easier to use and understand, since the facade has convenient methods for common tasks
- Make code that uses the library more readable, for the same reason
- Reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thereby allowing more flexibility in developing the system
- Wrap a collection of APIs with a single well-designed API