J
Jeremy Cowles
Disclaimer: This could be considered an ADO question, but, it really is a
question of code maintenance.
I have created a utility app that synchronizes MSSQL tables & stored
procedures as Classes in .NET. So Given the following table structure:
Table Name: ITEM
item_id varchar(20)
description varchar(40)
value int
The following Class would be generated:
'--------------------8<---------------------------------
Class ITEM
Public Structure Fields
Public Const item_id as String = "item_id"
Public Const description as String = "description"
Public Const value as String = "value"
End Structure
Function item_id(dbo as DataRow) as System.String
Return CastDB.ToString(dbo, Fields.item_id)
End Function
Function description(dbo as DataRow) as System.String
Return CastDB.ToString(dbo, Fields.description)
End Function
Function value(dbo as DataRow) as System.Int32
Return CastDB.ToInt32(dbo, Fields.integer)
End Function
End Class
'--------------------8<---------------------------------
So it allows you to use intellisense with your field names, and the classes
are automatically synchronized when if the database changes once it is
setup. The biggest advantage is that when a field (or other object)
changes, everything that uses that object in your app now throws a compile
error.
So I guess my question is this: what are the possible negative issues with
doing this?
Pros:
- allows intellisense with fields, tables, views and stored procedures
- simplifies database-to-code maintenance (shows errors when names change)
- provides easy access to field values
- requires less trips back to Query Analyzer to check data types etc...
Cons:
- complicates maintenance
TIA
~
Jeremy
question of code maintenance.
I have created a utility app that synchronizes MSSQL tables & stored
procedures as Classes in .NET. So Given the following table structure:
Table Name: ITEM
item_id varchar(20)
description varchar(40)
value int
The following Class would be generated:
'--------------------8<---------------------------------
Class ITEM
Public Structure Fields
Public Const item_id as String = "item_id"
Public Const description as String = "description"
Public Const value as String = "value"
End Structure
Function item_id(dbo as DataRow) as System.String
Return CastDB.ToString(dbo, Fields.item_id)
End Function
Function description(dbo as DataRow) as System.String
Return CastDB.ToString(dbo, Fields.description)
End Function
Function value(dbo as DataRow) as System.Int32
Return CastDB.ToInt32(dbo, Fields.integer)
End Function
End Class
'--------------------8<---------------------------------
So it allows you to use intellisense with your field names, and the classes
are automatically synchronized when if the database changes once it is
setup. The biggest advantage is that when a field (or other object)
changes, everything that uses that object in your app now throws a compile
error.
So I guess my question is this: what are the possible negative issues with
doing this?
Pros:
- allows intellisense with fields, tables, views and stored procedures
- simplifies database-to-code maintenance (shows errors when names change)
- provides easy access to field values
- requires less trips back to Query Analyzer to check data types etc...
Cons:
- complicates maintenance
TIA
~
Jeremy