Jan 10th, 2007, 10:07 AM
The case for the business/service tier
We are going through a spring and webflow adoption process in our project, and have come up against a basic question:
For our application, is the business tier really needed in a Spring+Webflow based application?
The argument for answering the question with NO is essentially:
The application's nature (see below) doesnt really mandate too much business logic as such, so the webflow can be configured to directly call a DAO, and respond back.
The nature of the application is such:
1. It is purely an intranet application.
2. It is an admin-type application; not directly end-user facing.
3. There is no likelihood in the current business horizon of the business tier being exposed separate from the UI.
The argument for answering the question with YES has been:
1. Separating business/service layer and the view layer is a best practice that transcends the particular nature of the application, and current horizon.
2. There are portions of the application with moderately complex logic that is specifically neither view-related nor data-related, and this must be housed in a 3rd tier - the middle tier.
#2 above has been answered with a suggestion to move this logic into the controller or action itself.
Does this seem right?
Having searched the archives a bit I came accross this thread with some pretty categorical statements favoring the YES answer.
Assuming that that thread doesnt apply specifically to the Spring Core+Webflow scenario; here're some questions that I'd love this forum to respond to:
1. The spring (and webflow) architecture &/or philosphy doesnt necessarily advocate a specific layering approach, but does it organically and naturally render the business layer less important or vestigal? At least in this specific instance?
2. Would a business/service tier be recommended regardless in a Webflow app?
I tend towards the YES camp; but would love to be wrong, should that be THE RIGHT THING.
Any light from the gurus would be great.
Jan 10th, 2007, 10:20 AM
Spring does not mandate any layering. In fact Spring does not force any constraints on the user regarding domain / business layer - this non-intrusiveness is one of the hallmarks of Spring. But your point #2 in the Yes path suggests that there should be a separate business layer, however lean it may be. It's always welcome to have a separation of concerns.
Jan 10th, 2007, 04:04 PM
I would have thought you want to write the code decoupled from the view technology. If you start moving your code into the controllers and you don't have anywhere to put the code that doesn't belong anywhere your fragmenting the application. I would have thought for the effort involved it would make sense to have a service layer.
On the flip-side of this, if your application is very simple and the extra layer doesn't really do anything, I can see why you might be tempted not to bother. I suppose its a judgement call.
Might be worth having a look at this.
Jan 11th, 2007, 10:25 AM
Is this application is part of corporate infrastructure? is this a stand alone application or does it communicate with other applications as well? if none of the above than sounds like abuse of technology and unnecessary extra cost to me. If this application is stand alone and doesn't interact with any other application i would just use any simple tool/language that i find to write it rather than hosting an app/web server for it.