Generating data layers and testing the results

From initial discussions of the technical architecture I think we are planning on handwriting all the stored procedures and the data objects that wrapper them. I'd much rather use LLBLGen or another data layer tool to automate this, but it may not be my decision. I'd love to hear anyone's experience using data layer tools. Ideally I'd like round-trip generation, but could consider generating the initial objects and maintaining them by hand. I read the Great Data Generation Layer Debate with interest, but it was a discussion of different tool styles instead of first hand reports on using the tools. Regardless of how we build the data layer, I'd like to use nUnit to test it. I've had great experiences with nUnit and many of the consultants agree, but the MCS architect I discussed it with thinks writing the tests will slow us down.

[What I'm reading: The Things They Carried A series of brilliantly written short stories about the adventures of a squad in Vietnam. I read it in a day, but it would make a great bedside book if you want to read 15 minutes a night.]

3 Comments

  • EntityBroker is my fav. tool for this type of thing. You don't need roundtripping, because it isn't a traditional code generator. It is pretty easy to use once you get the hang of it, but be forwarned that it is not nice if you don't play by the rules. They are improving the quality of the exceptions that are generated and making the code more robust, but the early betas, as cool as they where, did waste quite a bit of time tracking down bugs between my object schemas and the entity broker code. Still, when you consider the total number of hours saved (since you get automatic support for SQL, Oracle, OleDb, etc. and don't have to write a single line of DB code), you probably still come out ahead. Of course, my domain model is about 10x more complex than most projects, so I was really pushing the limits of what is possible. Most projects probably won't run into some of the issues I encountered.





    Of course, I don't think entity broker supports stored procs, but they suck anyway :-P

  • Handwriting stored procedures is a waste of time. There are some good generators available which will do this tedious job for you within seconds. I wrote LLBLGen just for this: to not have to write all those hundreds of stored procs and callcode :)





    EntityBroker is a competing product so I will not say anything about that ;) Stored procs are useful when you want finegrained security on the functionality level rather than the table level. In the next version of LLBLGen I will not generate stored procedures either, just code which at runtime generates an optimiZed query especially taylored for the situation. Tests showed that for performance this isn't a big deal, SQLServer f.e. is good in caching parameteriZed execution plans, also for adhoc queries with parameters.

  • Frans - NICE to see yet another one leaving the SP path. Fact is that in the past SP's were GREAT - today they are not really that different. for "simple things" you can also sometimes precompile command object.





    The flexibility you get by not having SP's is great - and on the security: I prefer to handle my security on the data layer OR the business layer (actually this is one of the additions for the next larger iteration of EntityBroker (2003.1), adding a COM+ like security mechanism back into the system).





    SP's are a pain - from versioning (integrating with source control) to different variants over different databases - NOT the fun part you actually want to have. SOmetimes VERY usefull, 99% of the time totally useless and just adding overhead.





    My advice:


    (a) try not towrite or have generated a single line data laye, use a generic library


    (b) if thats not possible, got for something like LLBGEN.


    (c) ONLY if you are a masichist - write al lthe stuff by hand. MAYBE you have a reason for this SOMETIMES, but mostly it is the same argument that says you should write everything in assembler: a wrong understanding of today's technologies.

Comments have been disabled for this content.