The #1 thing you must get right though is correctly typed (ie: data typed) parameters.
One of the issues with many of the frameworks is that under the covers they use methods like AddWithValue() to add values to a parameters collection. The problem is that when you finally see those sorts of problems, they are often in code that you didn’t write. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> |http://greglow.me<http://greglow.me/> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Tony Wright Sent: Thursday, 13 July 2017 2:33 PM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Re: Stored procedure only ORM 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 <gfke...@gmail.com<mailto:gfke...@gmail.com>> 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