I've never "struggled" with date formats or whatever. Simply knowing the
rules was good enough that for the past 3 years I've never had a problem
using parameters, I've never had a problem knowing when to cast them, or how
to use them. However... another person on the team using a string concat
almost exclusively and then there were injection problems. Won't have to
worry about it if you just use parameters with the command object. Sure,
the code isn't as clean (but clean is relative to the one who thinks it is
clean).
But, we also have a data wrapper (similar, but much cleaner than the data
access block) that everything uses and so we really just say:
dataObject.AddParameter("@param1", value1);
dataObject.AddParameter("@param2", value2);
DataTable result = dataObject.ExecuteTable(storedProc);
Nothing wrong with that, and of course, you can use overloads with
AddParameter to specify the type, size, direction, or lengh of value if you
want.
In the end end, it is a matter of taste and preference. Of couse, what is
more important than abiding by your own styles on a team, is to have a team
standard and it is always done the same, predictable, way, otherwise you end
up with 10 different ways of doing the same thing (as is the case in our
company) and it is a royal pain to switch from one project to another,
copy/paste, re-use, etc. There are some places where we use the string
concat, mainly, for any of our 23 different search screens, where we
dynamically generate a sql statement based on the search criteria. But we
have to do some serious pre-parsing to help mitigate injection attacks and
other such stuff first. It can be convenient. But in the end, regarding
stored procedure parameters, we always just use the Command object and
Parameters, that's what they are there for, and they already do much of what
we would have to write code for to do anyway, so why not just use them?
Besides, the concern isn't whether *we* who wrote them/works with them has
problems, but whether everyone else will, new people will, or when you
leave, whether it'll leave others in a rut until they learn all the *quirks*
that you failed to realize were there because you know your style so well,
others, they don't, eventaully work it out. That's a problem we're
struggling with now is that the original people aren't here anymore, and
they constantly argued how easy it was to do this or that with data access,
but once they left, others had to decipher all the *quirks* and rules and
conditions in which something actually works. Doesn't matter how
straight-forward something *appears*. It'll always be straight-forward to
the one who wrote it. The point is, don't do what is good for you, do what
is good for the company in the long run, and what is more productive, and
what more people, including beginners, are more likely to be familiar with,
or be ready to document it so thoroughly that it because counter productive
to do it a certain way because of constantly having to document document
document.
I've been in some interesting discussions/debates with other team members on
this issue. The one wants it this way, the other wants it that way and
there's not agreeing with anyone else. In the end, it is important to
establish company standards and that way, whether anyone likes it or not,
things will be done a certain, predictable way.
Thanks,
Shawn
)