I must agree. 2 years ago I designed a small web application where my SQL statements resided in a properties file and I cached them and retrieved them at run time from the cache. Although some SQL statements could be tweaked and cache updated without touching any code, some modified SQL statements required code updates. The properties file was rather messy because some statements were rather large. It also made it somewhat difficult navigating between DAO and SQL properties file when I was debugging or reviewing the code.
I have since changed my approach and included my SQL as static final data members to my DAOs and have organized my DAOs from a business perspective where they usually reside in the same package as my other business components that support the appropriate business rules. I must say, this has been much easier to maintain although a change in the SQL requires code recompilation. There may be a better approach, but this one has worked for me so far. robert > -----Original Message----- > From: Vikram Goyal01 [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 8:43 AM > To: Struts Users Mailing List > Subject: RE: SQL STatements in a Properties file. > > > If you have to do research for DAO's then it means that your > documentation is poor. The person doing maintenance should have > access to the DAO's and the documentation (SQL/JavaDoc). I find > that putting all SQL's in one place gets ugly. After all, think > of big systems where the queries are not only complex, but are > miles long. Rather, with proper documentation, I can let people > be pointed in the right direction and take appropriate decisions. > This is one level of abstraction that I think is totally unnecessary. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 5:29 PM > To: Struts Users Mailing List > Subject: RE: SQL STatements in a Properties file. > > > The reason for putting your SQL in a properties files is so that you or > whomever is doing research or maintenance on the code can find all of the > SQL in one place, instead of having to search all over for DAO's ( which > can get pretty ugly). Abstraction is usually good, obfuscation is not > good. > > Jim Berg > Sr. Software Specialist > PSCI > 610-270-4158 > [EMAIL PROTECTED] > > > > > "Vikram Goyal01" > > <vikram_goyal01@infosy > > s.com> > > To: "Struts > Users Mailing List", Struts-Atlanta > > > 07-Jun-2002 00:55 cc: > > Please respond to Subject: RE: > SQL STatements in a Properties file. > "Struts Users Mailing > > List" > > <[EMAIL PROTECTED] > > pache.org> > > > > > > > > > I am not quite sure that putting your SQL in a properties file is such a > good idea. Whats the advantage? > If the advantage is that you dont have to change the source code > because of > query changes, then I think that it is misleading. If the query changes, > there must have been a business requriement for it -- > you have to change > functionality somewhere --> Means you have to change your source code to > take advantage of this new query somewhere down the line (EJB, Action, JSP > ) --> So you end up touching your source code. The whole idea of DAO's is > to abstract your queries and data access. Having another level of > abstraction is IMHO pointless. > > Rgs > Vikram > > -----Original Message----- > From: James Mitchell [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 07, 2002 4:44 AM > To: Struts Users Mailing List > Subject: RE: SQL STatements in a Properties file. > > > The framework knows nothing of sql. > > However, I have also pondered the using the message resources for > something > like this. > I guess if your data layer had access to the message > resources....you could > do something like this. > > sql.customers.get=Select * from customers > sql.customer.get=Select * from customers where id = {0} > sql.customer.update=update customers set name={0}, address={1} where id = > {3} > sql.customer.delete=detete from customers where id = {0} > > Although, this can get pretty messy quickly. > Have you considered using an OR tool??? > > > James Mitchell > Software Engineer\Struts Evangelist > Struts-Atlanta, the "Open Minded Developer Network" > http://struts-atlanta.open-tools.org > ICQ: 27651409 > AOLIM: jmitchtx (and NO I don't use AOL;) > > > > -----Original Message----- > > From: Olikkadavath, Bobby [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 06, 2002 1:57 PM > > To: [EMAIL PROTECTED] > > Subject: SQL STatements in a Properties file. > > > > > > Hi, > > A newbie question... > > I want to dynamically pickup SQL queries from a Properties file > > (Similar to > > how we use the bean : Message and the > ApplicationResourceProperties FIle > > for Static content in a JSP). > > Does the framework have an implementation exclusively for this or should > I > > create something on my own. > > > > Thanks > > Bobby > > > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
