Hi,
I wondering if you can help me settle a debate i'm having with my boss about correctness versus speed.

He thinks that for lots of enum tables we have in our database, e.g. tables you use to populate dropdowns such as a list of Countries (Id and Name columns), we should have a single DA layer function call where we pass in the "table name" and create the SQL query on the fly, e.g. "SELECT Id, Name FROM" + tablename . Then return a List of a custom NameValuePair class. This DA layer would be called on the front end via the BizLogicLayer by the following mechanism...

Say you have a dumb DTO instantiated class called Person, which has a CountryId integer property (basically the foreign key value). And you're now on a Person edit screen. He wants to decorate the CountryId property of the Person class with an attribute that tells you the "table name" and extract this via refelection to then pass to the DA layer (as above) to get all the country values for the person edit screen.

My technique would be to create a DA method and stored proc per enum table, and on the edit screen, call the correct DA layer via the BizLayer to get the name/value pairs for the the dropdowns

His thought is that with lots of enum tables we have to create lots of repetitve code to do the same job, e.g. return name value pairs.

My argument is that everything is strongly typed, it's implicit, but it does mean a little bit more coding. But everyone will know when calling the DA layer, they'll have something like DA.GetCountries, DA.GetColors, etc, etc.

What he's proposing does work, but its very dirty using dynamic SQL and using dumb DTOs tied to table names. Can you give me some thoughts on how I can turn his thoughts around on this one?!

either way its correct.....