Uh, wrote:
...I should add that we actually have another layer on top of LLBLGen, which we're using as the "Business" layer, and LLBLGen is used inside this layer. In practice it's an Adapter pattern implementation.... This does give us an opportunity to use stored procs instead of LLBLGen for CRUD, but the whole point of using LLBLGen was to get away from that kind of mind-numbing (and therefore error prone) coding.
I see it.
As is obvious, the bad news is that as soon as one is using a SP-based solution, then one inherits all of the awful baggage that comes with using SPs.
On a previous project, I had to use SPs and could not use an OR-mapper. I did NOT want to write a single line of SQL. What I ended up doing was writting a few simple CodeSmith templates to generate the stock SPs, SelectOne(), SelectAll(), SelectByKey1, SelectByKey2, SelectByKeyN, DeleteOne(), and so on. It wasn't that bad. The SPs were generated at the click of a button. Abstract classes were bound to the SPs; but, since the classes were also generated, that was not a problem. Concrete hand-written classes inherited from the Abstract classes. And so on. Not a new idea; but, it works. So, in your case, I would probably recommend using a code generator, like LLBLGen Templage Designer or CodeSmith or MyGeneration or any of the other fine products out there. Then, use LLBLGen to generate objects that bind to those SPs, and so on.
Just a thought.
HTH.
Thank you.
-- Mark Kamoski