• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Database validation in Action or Bean?

 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Sheriff
Posts: 6450
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
reply
    Bookmark Topic Watch Topic
  • New Topic