There is nothing inherently wrong with an ORM just for stored procs, but what I think your are really talking about is the ability to drag your stored procedures onto a canvas and have it generate the code to be able to interact with the stored procedure. That's all ORMs really are: code generators, and most are not very good at it. The reason people steer clear of the more bulky ORMs is that they are slow to load, perform badly and sometimes generate some weird and wacky code.
I often use Entity Framework canvas to generate all the code for my stored procs. It wipes out a whole class of bugs, as it works so well that any issues are never due to the code generated, but are caused by issues in the stored procs itself or application logic. But I prefer not to use anything else. (I certainly don't use lazy loading, which might appear to give you some benefits in delivering features faster, but at the expense of massive technical debt, much slower performance, and usually a lot a network traffic. At the very least, use eager loading, and always be in control of exactly what is being loaded in each request.) Some time ago I was considering writing a canvas to sit over the top of Dapper so that I could generate Dapper code on dragging and dropping a stored procedure onto the canvas, however the effort required to do that became prohibitive. It would have been awesome, though! On Wed, Jul 12, 2017 at 6:19 PM, Greg Keogh <[email protected]> wrote: > Thanks I will check it out >> > > I've used Dapper to read SQLite, but not much more than that. I found it > easy to use, so I'll guess it's probably lightweight and good for SQL procs > too -- *GK* >
