Whether DAO layer is redundant when using stored procedure?

[cpplus]

Hi folks

I'm fresh to Spring framework and I'm refactoring a legacy web application.
The original architecture is Html-Servlet-Stored proc. The stored procedures are designed for query data only, no creation, no update and no delete.

I plan to use Spring framework during refactoring.
I searched with Spring samples and articles here, most commonly used architecture of Spring is: WebMVC-Service-DAO.

In my case, I could call stored procedure in the Service layer(actually, I havn't found better way to call stored procedure in DAO layer, if you have, please help to indicate).

So my question comes here: Whether the DAO layer is needed when using stored procedure? Or call stored procedure from the Service bean directly is good manner or bad?


Thanks!

[rstearns01]

It doesn't sound as if your app is complicated enough to prohibit a separate data access layer, so even though it may not be needed, it's a wonderful idea. I am having a similar discussion with a collegue that doesn't see much "bang for the buck" here since the database, for politcal reasons, won't change for a long time and my DAOs (thanks to Spring) are a few instance variables and some one line methods. So for what it's worth, I'll try my persuasion here.

As sharper tools than I have mentioned, a primary advantage is creating and programming to an interface to your data access layer, which hides the specific details of construction of your business objects, and creates a single point of change should you add, consolidate, or enhance your sprocs. If your BOs are compositions or contain aggregations, those are usually built by calling multiple sprocs. There is no need to expose your business logic to the grunt work of doing this, especially in multiple places. Ask for an object and get it - that's all your business tier should have to deal with.

The second advantage is that by using an interface you can place your transactional demarcs at the method level, or configure Spring to use declarative transactions for the interface methods - useful (and simpler) for those compositional objects.

Thirdly, you may want to switch to JdbcTemplates, add an O/R mapping layer or (shudder) entity beans in the future. You want to hide these details as much as possible, because I may have to maintain that program one day. :wink:

While it's a good idea to use the YAGNI principal during design and avoid thinking about what-ifs, this is a simple, easy form of insurance.