Revised Generic 'T, K' Database Component

Please see my previous article 'Generic 'T, K' Database Component' written on December 17, 2005. In that article, I discussed why, I built this component as a generic<T, K>.

What I did not discuss is how the component changed from a code/design point of view while not changing in my original intent.

  • I wanted to cut down on the lines of code.
  • I wanted to use generics and see where it would take in while writing a database component.
  • I wanted to see if using generics for something other then array/collection pushing/popping was even reasonable.

What I found was,

  • Generics will change the way we do things.
  • Generics will change the way we think about writing re-usable components.
  • Generics got me re-excited about development.
  • Power...generics opens the door to a new future.

Point of interest in the code and within the solution,

  • In the SqlCommand object, I use the SqlCommandBuilder.DeriveParameters because I hate embedding stored procedure variables in code. Embedding stored procedure variables, etc., in my book, tightly couples my layers too closely to my code. What does that mean...change a stored procedure, you have to change code.
  • I added the update for Typed DataSets because I could. 99% of the time, I use stored procedures so I use either one of the creates where I pass in the SQL statement/stored procedure.
  • The Interface is not completed here in this version.


Similar Articles