Note that all I need is a connection string … My nant build target looks something like the following. I leave the discovery of this as an exercise to the reader. There are some simple algorithms that I use to determine whether a stored procedure is a read-single, read-multiple, create-new, or something else entirely. Compile assemblies dependent upon the above. Compile SomeDatabase.g.cs into assembly .ĥ.
#CODESMITH GENERATOR SERIAL CODE#
Run the code generator to produce SomeDatabase.g.cs.Ĥ. I use the code generator in our builds in the following manner:Ģ. The generated domain types that correspond to tables are rather big, so I won’t include them here. OutputParameter.Direction = ParameterDirection.Output SqlCommand command = new SqlCommand("dbo.CreateFooThing", this._connection) Ĭommand.CommandType = CommandType.StoredProcedure Ĭ( new accountID)) Ĭ( new (checkNumber = null) ? : ( object) checkNumber)) Ĭ( new (currenc圜ode = null) ? : ( object) currenc圜ode)) Ĭ( new (issuedDate = DateTime.MinValue) ? : ( object) issuedDate)) Ĭ( new (someDate = DateTime.MinValue) ? : ( object) someDate)) Ĭ( new (reason = null) ? : ( object) reason)) Ĭ( new (payee = null) ? : ( object) payee)) Public long CreateFooThing( int batchID, long accountID, string checkNumber, decimal amount, string currenc圜ode,ĭateTime issuedDate, DateTime someDate, string reason, string payee) So what does the generated stored procedure wrapper code look like? Here’s a sample for a read-single-record sproc:
Awareness of DbNull and CLR value type collisions. Automatic mapping of SQL OUT and INOUT params to method return types.Ħ. If the sproc takes in a smallint, you won’t get away with shoving a System.Int64 in there.ĥ. Automatic type mapping from SQL to CLR types and vice-versa. Automatic column mapping from sproc result sets to strongly typed domain objects.Ĥ. Compile-time failures when a stored procedure interface has changed and the application code hasn’t.ģ. There has since been some minor maintenance to it, but the overall time commitment has been exceedingly small. Start to finish was under three hours, and I had no CodeSmith experience before, other than poking around in the.
#CODESMITH GENERATOR SERIAL TRIAL#
Some history: last summer I built a CodeSmith template to do the codegen, based on sample code from CodeSmith and some trial and error. The codegen implementation will work on just about any database (it is not team-specific), and if you adhere to a few basic rules with your sproc names, the generated code will be very nice. Classes with single-record and multiple-record column-to-property converters are generated for each table in the database as well. Methods are generated for every stored procedure, and multiple sproc calls can be used inside the same using block, as the SqlConnection is maintained for the undisposed life of the SomeDatabase instance. In the above code, the FooThing and SomeDatabase types are 100% generated code. Return FooThing.CreateFromDataReader(db.ReadFooThing(fooID)) Using (SomeDatabase db = new SomeDatabase())
0 kommentar(er)
