How do you guys handle String constants for table names, columns, etc.
Instead of having the strings hardcoded in all the SQL statements, I was thinking isn't it better to have them as constants in one location? My project lead says to use Enum values. What is wrong with having a public static final String for every column name and table name? Is there a better way to construct this? It seems like a lot of pain in the butt to have an enum or string constants.
[400 byte] By [
smiles78a] at [2007-11-27 11:08:54]
# 1
> Instead of having the strings hardcoded in all the
> SQL statements, I was thinking isn't it better to
> have them as constants in one location?
No. I can read SQL statements. I sure as hell don't want to flip back and forth to another class just to figure out what the query is.
> My project
> lead says to use Enum values.
That sounds like a bad idea, too.
> What is wrong with
> having a public static final String for every column
> name and table name?
See above. Understanding and readability are lost, with absolutely no gain that I can see.
> Is there a better way to construct this?
Yes, just write the SQL and keep it in the DAO that uses it.
> It seems like a lot of pain in the
> butt to have an enum or string constants.
Yes, it is. Don't do either. Just write the SQL as static final Strings in the DAO class that uses them.
%
# 2
> Yes, it is. Don't do either. Just write the SQL as
> static final Strings in the DAO class that uses
> them.
>
Well, this is going to sound complicated, but I wanted to be able to pass to my dao a condition. Within a table I could choose to match 1 field to a value, 2 fields to a value, do AND or OR, etc. Infinate possibilities. Due to what I'm working on we have to account for numerous types of queries. So I have a class which has :
- columnName
- value to match
The actual implementation will also take into account different operators <, >, etc... so I have an enum set up to limit the setting of the operator to only those which are valid
Anyhow, so I'm having to set the column name there, in my dao, in a class which I'm using to map the result set to an object (yes there are tools for this but it's not by call I have to use straight JDBC)
So that type of stuff isn't in one place. It is in at least 3 classes.
Is it still best to use just hardcoded strings. If the DB changes that's several places to change the code, but is that the best thing?
# 3
> Well, this is going to sound complicated, but I
> wanted to be able to pass to my dao a condition.
> Within a table I could choose to match 1 field to a
> value, 2 fields to a value, do AND or OR, etc.
> Infinate possibilities. Due to what I'm working on
> we have to account for numerous types of queries. So
> I have a class which has :
> columnName
> value to match
I still don't like the idea of putting the table and column names in static Strings. Write the criteria where they're needed.
>
> The actual implementation will also take into account
> different operators <, >, etc... so I have an enum
> set up to limit the setting of the operator to only
> those which are valid
Sounds like you're trying to write your own custom query language now. What's the benefit? Others have already done it, probably better than you will (e.g., Hibernate, Spring)
>
> Anyhow, so I'm having to set the column name there,
> in my dao, in a class which I'm using to map the
> result set to an object (yes there are tools for this
> but it's not by call I have to use straight JDBC)
>
> So that type of stuff isn't in one place. It is in at
> least 3 classes.
>
> Is it still best to use just hardcoded strings. If
> the DB changes that's several places to change the
> code, but is that the best thing?
Still don't see the benefit to you.
%
# 4
> Instead of having the strings hardcoded in all the
> SQL statements, I was thinking isn't it better to
> have them as constants in one location?
No.
> My project
> lead says to use Enum values.
Hopefully because the lead didn't understand what you were going to do with them.
# 5
>
> Well, this is going to sound complicated, but I
> wanted to be able to pass to my dao a condition.
> Within a table I could choose to match 1 field to a
> value, 2 fields to a value, do AND or OR, etc.
> Infinate possibilities.
Doesn't sound complicated to me.
You create a condition DTO. Data members look as follow
String nameOp1;
String nameOp2;
Operator op
You can combine the above into a generic class or just leave it as is.
Then you create an interpreter where a call looks like
String whereSql = "(1=1)";
for(..)
if (op != null)
whereSql += " and (" + InterpretOp(op1, op2, op, "name")
You can complicate it further by adding expressions to your op tree which allows you to vary the 'and' in the above and add parens, etc.
Once broken down it is rather trivial to implement for specific column names.
Using it is a bit more complicated especially if you add expressions.
