RE: Stored procedure only ORM

[罗格雷格博士]

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

Re: Stored procedure only ORM

[Tony Wright]

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  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*
>

Re: Stored procedure only ORM

[Greg Keogh]

>
> 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*

Re: Stored procedure only ORM

[Tom Rutter]

Thanks I will check it out

On Tuesday, 11 July 2017, William Luu  wrote:

> You could try Dapper.
>
> https://github.com/StackExchange/Dapper#stored-procedures
>
> It's a micro ORM made by the people behind StackOverflow and claims to be
> fairly fast.
>
> On 11 July 2017 at 18:17, Tom Rutter  > wrote:
>
>> Anyone here had any fairly recent experience with an ORM (EF?) to run
>> only stored procedures? Any gotchas or recommendations? The sql database I
>> need to interact with has to have everything run via stored procedures. The
>> last time I did this sort of thing we used ado.net directly. That
>> obviously worked well but was tedious and boring to implement.
>>
>>
>

Re: Stored procedure only ORM

[William Luu]

You could try Dapper.

https://github.com/StackExchange/Dapper#stored-procedures

It's a micro ORM made by the people behind StackOverflow and claims to be
fairly fast.

On 11 July 2017 at 18:17, Tom Rutter  wrote:

> Anyone here had any fairly recent experience with an ORM (EF?) to run only
> stored procedures? Any gotchas or recommendations? The sql database I need
> to interact with has to have everything run via stored procedures. The last
> time I did this sort of thing we used ado.net directly. That obviously
> worked well but was tedious and boring to implement.
>
>

Re: Stored procedure only ORM

[Greg Keogh]

>
> Anyone here had any fairly recent experience with an ORM (EF?) to run only
>> stored procedures?
>>
>
Weirdly enough, I've found this to be quite a comfortable thing to do. If
you make a commitment up-front that most of the grunt work will be done in
procs, which can happen for staffing/skill reasons, then adding the procs
to the EDMX generates nice wrapper methods over them. It seems like
overkill just to use EF just for wrapping proc calls, but I've found it
really convenient. Otherwise, it's raw old ADO.NET code, which is so early
21st century! Overall though I suppose it depends just how much extra
mileage you get either way.

*GK*

Re: Stored procedure only ORM

[Tom Rutter]

What's an alternative? The database only allows interaction via stored
procs.

On Tue, Jul 11, 2017 at 6:21 PM, Craig van Nieuwkerk 
wrote:

> Stored proc only ORM seems like hedging your bets and coming up with the
> worst of both worlds.
>
> On Tue, Jul 11, 2017 at 6:17 PM, Tom Rutter  wrote:
>
>> Anyone here had any fairly recent experience with an ORM (EF?) to run
>> only stored procedures? Any gotchas or recommendations? The sql database I
>> need to interact with has to have everything run via stored procedures. The
>> last time I did this sort of thing we used ado.net directly. That
>> obviously worked well but was tedious and boring to implement.
>>
>>
>

Re: Stored procedure only ORM

[Craig van Nieuwkerk]

Stored proc only ORM seems like hedging your bets and coming up with the
worst of both worlds.

On Tue, Jul 11, 2017 at 6:17 PM, Tom Rutter  wrote:

> Anyone here had any fairly recent experience with an ORM (EF?) to run only
> stored procedures? Any gotchas or recommendations? The sql database I need
> to interact with has to have everything run via stored procedures. The last
> time I did this sort of thing we used ado.net directly. That obviously
> worked well but was tedious and boring to implement.
>
>

Stored procedure only ORM

[Tom Rutter]

Anyone here had any fairly recent experience with an ORM (EF?) to run only
stored procedures? Any gotchas or recommendations? The sql database I need
to interact with has to have everything run via stored procedures. The last
time I did this sort of thing we used ado.net directly. That obviously
worked well but was tedious and boring to implement.