Data access layer code generator , Reccomendations ?
-
There are many data access layer tools , so I do not know where to start . I just want to get out of repetitive boiler plate coding . But I have a few requirments:- 1) Works with MsSQL . ( Virtually all should) 2) Produce C# code (Again - all should) 3) Must produce a data object that maps onto a row of a table .( This has been the stumbling block) 4) The data object must have no references to any DB/connection . I.e pure data . Maybe a few Ctors , ideally a struct , but if a class must support ICloneable . 5) Icing on the cake is if the data object overrides = in order to make a value comparison ( I know MS advise against it but its useful). 6) Collections of the data objects would be nice Why the 1:1 row to object ? Well I found over the years that if I put all my effort into a normalised DB then the code almost falls into place if I produce a 1:1 row - > object . Then I use an object that maps to a table or stored procs in order to communicate with the underlying tables . Not haveing any reference to the DB in the data object means it is as light as possible in the GUI
-
There are many data access layer tools , so I do not know where to start . I just want to get out of repetitive boiler plate coding . But I have a few requirments:- 1) Works with MsSQL . ( Virtually all should) 2) Produce C# code (Again - all should) 3) Must produce a data object that maps onto a row of a table .( This has been the stumbling block) 4) The data object must have no references to any DB/connection . I.e pure data . Maybe a few Ctors , ideally a struct , but if a class must support ICloneable . 5) Icing on the cake is if the data object overrides = in order to make a value comparison ( I know MS advise against it but its useful). 6) Collections of the data objects would be nice Why the 1:1 row to object ? Well I found over the years that if I put all my effort into a normalised DB then the code almost falls into place if I produce a 1:1 row - > object . Then I use an object that maps to a table or stored procs in order to communicate with the underlying tables . Not haveing any reference to the DB in the data object means it is as light as possible in the GUI
take a look at LLBLGen