3 Responses to Custom Objects and Tiered Development II // 2.0

My only concern with the code is, although it is clean and easy to read you have nearly 4 classes for each data entity you plan to pull out of the database. If you were mapping 100 tables, this would become a difficult to manage project having to change 4 classes everytime the a change was made to a table. As far as using the column name-index mapping in the Layout class, this could haunt someone a little bit if they didn\’t control the database themselves. Although in a good team environment, db admin\’s should never make crazy changes, it would be quite easy for someone to change the column order of a select command, breaking your app in the process.

//Quote//If you
were mapping 100 tables, this would become a difficult to manage
project having to change 4 classes everytime the a change was made to a
table.//End QuoteI understand what you are saying. However, I find this method more maintainable then any shorter version(s). Yes, I have to go to 4 places (the stored procedure, the layout, the controller and then to the business object (to add the property)), but I know exactly where to go, and actually it takes me less time to do this, because I know where everything is, and I am not hunting for it. Obviously, its a subjective choice, but I stick by the model above.//QuoteAs far
as using the column name-index mapping in the Layout class, this could
haunt someone a little bit if they didn\’t control the database
themselves. //End QuoteAnother good observation. If you don\’t have that granular control, then sure, go back to the NamedColumn approach. However, there is a small price to pay every time one needs to do a lookup. When you ask for a value from the datareader with a name (Ex "EmployeeID"), instead of an ordinal (EmployeeLayout.EmployeeID = 0), then there is a lookup involved, you are just encapsulated from it.But here is another gotcha.Select EmpID, DeptID, LastName, FirstName from dbo.EmployeeYour observation is changing the ordinal positions. Like:Select EmpID, DeptID, LastName, MiddleName, FirstName from dbo.EmployeeAnd you are correct.The dba could also do an aliasSelect EmpID, e.DeptID as EmployeeDeptID , d.DeptID as DepartmentDeptID, LastName, FirstName from dbo.Employee left outer join dbo.Department in e.DeptID = d.DeptIDObviously this doesn\’t make a lot of sense from a common sense perspective, but if the dba has to "un-ambigious-ize" a column, then the name changes for the .Net side of things as well.But your observation is valid, and the choice left to the end-developer.I just prefer the Ordinal method, because I believe that gives me the utmost performance, and the Layout gives me readability. And I write the TSQL code myself 99% of the time.A coworker has actually created a code generation tool for all this (as above), which creates the DataLayer, the Layouts, the Controllers, the BusinessObjects, the Collections and the Controller.Deserializers. This is company property unfortunately, so I can\’t post it. But it makes quick work of all this stuff when there is a working database to pull from.I appreciate your comments.