Meaningless Drivel is fun!*
The moose likes Struts and the fly likes Database validation in Action or Bean? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "Database validation in Action or Bean?" Watch "Database validation in Action or Bean?" New topic
Author

Database validation in Action or Bean?

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

According to the Accessing a Database documentation, a DataSource can be obtained in an Actions execute method.
Is this really where that type of logic should take place? I mean, if I need to validate a users authentication against a database, should it take place in the Action class? Because I have seen several examples where it is suggested that the Bean class handle that type of authentication. The problem with that is I have no access to the servlet from the Bean class.
A simple example is Tom's STRUTS 1.1 Tutorial from the newsletter. He shows authentication happening in the LoginBean class.
So what is the appropriate way to handle this? What is the point in the LoginBean or similar class if it is not to handle any validation?


GenRocket - Experts at Building Test Data
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Ok, after going through Sue's Struts Framework book again, there is a small secion (3.10) about the Business Logic. Basically it says that the business logic should reside in JavaBeans or EJB's. So what I am wondering is how to develop a JavaBean that has access to the Servlet Context so that I can get to my DataSource.
[ September 30, 2003: Message edited by: Gregg Bolinger ]
Jason Menard
Sheriff

Joined: Nov 09, 2000
Posts: 6450
Preferably your business objects have access to the datasource via JNDI. Barring that, you could pass in Connections from your datasource as parameters to methods. Another way to make objects available to the business layer is to use singletons, possibly initialized via a Plugin. In any event, your business objects should be ignorant of the web tier, and therefore should know nothing of the ServletContext, sessions, requests, and the like.
[ September 30, 2003: Message edited by: Jason Menard ]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Ok, thanks Jason. For now, since my app is pretty simple, I am doing all that in the Action class. Later, as the app grows, I can rip it out into it's own layer.
Thanks.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Personally, I feel that a Servlet Filter (if you are using J2EE 1.3 or above) is a much better choice for Authentication and Authorization... regardless of what you choose I suggest that you try and keep as much business logic out of your Actions as possible. It makes for a more maintainable and testable solution.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
My .02 cents is to design your app as a console app.
No, really, I mean it.
Stop laughing.
The end point of this console app is to produce a simple JavaBean that holds all the data your page needs to display(name, date, etc). This reduces the scope of your Struts layer to exactly what it should be(IMO): the gymnastics of validation, data presenting, and navigation. Thus, your struts layer doesn't actually perform any business logic at all (outside of presentation, validation, and navigation): it simply asks an internal business engine to do so.
M
ps - I advise against making the javabean the actual form itself: there's no real need for this sort of coupling. Make it a member variable on the relevant form.


Java Regular Expressions
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Max Habibi:
My .02 cents is to design your app as a console app.
No, really, I mean it.
Stop laughing.
The end point of this console app is to produce a simple JavaBean that holds all the data your page needs to display(name, date, etc). This reduces the scope of your Struts layer to exactly what it should be(IMO): the gymnastics of validation, data presenting, and navigation. Thus, your struts layer doesn't actually perform any business logic at all (outside of presentation, validation, and navigation): it simply asks an internal business engine to do so.
M
ps - I advise against making the javabean the actual form itself: there's no real need for this sort of coupling. Make it a member variable on the relevant form.

This is an interesting concept. Is this something you have done? I like the idea of it. I just wonder how hard it would be for me to implement. How do you talk between the 2.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Actually, yes. I did for a fairly large project. I provided layer who's entire point is to act as an intermediately for the Actions. They provide whatever data a given ActionForm needs as a JavaBean, and the ActionForm keeps that Javabean as a private member variable. That same layer also translates the requests of the ActionForm to requests for the business layer proper. It's a controller, if you will.
There are a lot of advantages, IMO, to this system. For example, in a larger project where you a lot of developers, one team can work on presentation and navigation, while another is concurrently working on implementing the business logic. Another is that the various layers can be tested independently.
All in all, it's a fairly straightforward, IMO.
M
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Database validation in Action or Bean?