Re: Entity Framework - the lay of the land

[David Connors]

On Tue., 3 Jan. 2017, 7:16 pm Greg Keogh,  wrote:

> What I liked about netTiers was that the CRUD was basically table-based
> and not over-engineered like many famous ORMs (including EF) and it just
> threw a really handy bridge at the lowest useful level between classes and
> tables. Maybe even David C wouldn't turn his nose up at that?!
>

I probably would. But I have a very different set of drivers to most
everyobe else in this thread.

David.

> --
David Connors
da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363

Re: Entity Framework - the lay of the land

[Grant Maw]

Sorry for the late reply, only just seen this thread. As Stephen Price said
back in September, I have been using CodeSmith to generate my stored procs
and DAL for well over a decade. Our templates have changed as language
improvements and new product features have come along, but the underlying
principles and methodology remain the same.

We generate the boilerplate code which is based on patterns we've used and
updated over many years, and which have proven themselves repeatedly on
projects of all different sizes. These produce stored procs  and the
associated C# objects that are simple, predictable, easy to follow, and
fast. This code just does simple CRUD operations, nothing more. It can then
put all the code inside generated .sln and .csproj files, writes some basic
tests for the work it's done, and so once you've designed your schema you
can have a ready to go VS project in just a few minutes. For web apps,
we've written templated asp.net pages as well (so I guess we had our own
"scaffolding" long before the term became popular), which we constantly
update as technology evolves. We don't need to wait for EF to catch up with
the latest developments in SQL Server, for example, we just roll our own.
If we get it wrong, we can easily change it.

All this provides us with the skeleton of an app, allowing us to
concentrate our efforts into we then modifying the parts of it that need
changing to suit the requirements of the particular job at hand. Typically
our generated object design is a close match to the table designs, and this
doesn't work in all scenarios, so changes are necessary for this and a
variety of other reasons depending on the task at hand (this is the
"effort" side of the equation that David refers to above).

I've looked at EF, and a few other ORMs, and I have not found a single
solitary advantage to changing, other than to become one of the cool kids
using the latest whatzit technology. I prefer to concentrate on building
things rather than learning new technologies that offer me no benefit,
which can be a nightmare to debug, and which can be taken away at any time.
What will happen if MS does to EF what they did to Silverlight, for
example? What's going to happen to all those folks who invested heavily in
Telerik's now-discontinued ORM?

My take on all this is that you need to find a data access method that you
are comfortable with, either home grown, or open source, and stick to it. I
know it's not as simple as that when you have an employer who demands that
you know such and such tech, but that's our experience.


On 17 September 2016 at 11:52, Stephen Price 
wrote:

> Awesome thread guys.
>
>
> Just to throw in some of my comments and views.
>
>
> For Greg Low: Partly jokingly, I thought you would have loved the use of
> EF. From a business perspective, no shortage of projects you can fly into
> at the last moment, and save the damsel in distress. Wave your trusty SQL
> cape, collect big pay check and fly off to the next project needing saving.
>
>
> Myself, being a developer, love being able to code linq style against the
> EF database context and not have to break out the SQL. I've always told
> myself my T-SQL is a weak point, but this week I could arguably discredit
> my opinion on myself. I had some code that generated a magic number on the
> end of a number in C#. Realised I needed to run it from another codebase
> which shares the database so chose to write the same function in t-sql. It
> worked but I doubted myself too much (ie will it work under all
> conditions?). Got another guy to code review it and he said it looked fine.
> I ended up simplifying it and then discovered that the EF reverse code gen
> tool we are using (which generates our EF code from the database) doesn't
> gen EF code for SQL Functions.
>
> So now I realise as I type this that we are using a tool to generate
> (some) EF code from our database so that EF can generate our database.
> Poised to disappear up my own recursive arse any moment here!
>
> My usual way of optimising EF is to use dtos.  Be as explicit as possible
> when querying for what I want. Not ideal, but this conversation thread has
> taken me back to when I was working with Grant Maw (hi Grant! Hes on
> holidays In Hawaii right now so probably not reading along) where he uses
> CodeSmith to magically gen his boilerplate ADO.net layers from his
> databases. He's probably still enjoying his stubborn refusal to use an ORM
> as we speak.
>
> New and shiney is not always the best thing down the track.
>
> It's opened my eyes. Perhaps time to renew my CodeSmith and see how far
> their out of the box templates have come.
>
> As David pointed out good work requires effort. We are craftsmen. We need
> to find the balance between doing good work with our tools and having our
> tools do good work.
>
> Enjoy your weekend all!
> --
> *From:* ozdotnet-boun...@ozdotnet.com 

Re: Entity Framework - the lay of the land

[Tony Wright]

I have used Entity Framework myself but generally simply map to stored
procs. Some Linq occasionally creeps in, but the biggest gripe I have with
EF is the lazy loading. It can get nasty very quickly generating ridiculous
amounts of unnecessary traffic as it loads every linked object it comes
across. At the very least if people are going to use EF, turn off lazy
loading and use eager loading instead.

Stored procs are best, of course, as it's often much easier to get stored
proc changes through change control in enterprises than code changes in an
app, which requires virtually a compete redeploy.

Things really slow down in the mapping layer, especially when you are
custom loading related objects. Way to destroy performance. If you can
return an EF stored proc results class without any extra mapping it can
increase productivity. There is a natural boundary if returning the results
from webapi calls to angular, for example.

Of course, I think I lost a job recently because they thought lazy loading
was the best thing since sliced bread. Deluded I think in thinking they
were getting a productivity increase that wouldn't be offset by a massive
maintenance bill and slow application.

On 3 Jan 2017 4:16 PM, "Greg Keogh"  wrote:

> Hi Grant et al,
>
> You're psychic, as I was going to post on this old topic later in the
> week, as I've rejigged my thinking a little in recent months.
>
> I also used CodeSmith to make CRUD for a few good years and I was
> impressed by how easy it was. I used the netTiers templates, not handmade.
> What I liked about netTiers was that the CRUD was basically table-based and
> not over-engineered like many famous ORMs (including EF) and it just threw
> a really handy bridge at the lowest useful level between classes and
> tables. Maybe even David C wouldn't turn his nose up at that?!
>
> Both EF and netTiers support "deep loading" by effortlessly following
> joins, and that's about the only advanced feature of either of them that I
> ever used.
>
> In recent months in both hobby code and some real apps I faced that choice
> of where to swing the pendulum of manipulating data ... towards the
> database or towards the app code. I have decided that all basic data
> manipulation like WHERE, ORDER, OVER, JOIN, SELECT, etc should be done in
> stored procs and not in the ORM or app code. You just can't beat the
> performance and clarity of doing this in the DB. After all, that's what
> it's built for! And EF is great for simply mapping the procs to methods and
> DTO classes.
>
> I now put a fence up in my mind to put all basic data manipulation in the
> DB on one side and strictly business logic in the code on the other side.
> Sometimes you have to shred and knit DTOs, but that should be in app code
> as well.
>
> And Grant's concern about dependency on specific ORMs is quite valid. We
> have one app that heavily used EF v4 and the self-tracking entities, which
> were deprecated, and now we're stuck and can't get to EF6 without
> industrial effort. Imagine trying to completely change your ORM brand.
>
> So in summary I have decided for now that ORMs are still a real coding
> productivity boost, but only when used for basic CRUD and DTOs.
>
> *Greg K*
>

Re: Entity Framework - the lay of the land

[Greg Keogh]

>
> >turn off lazy loading and use eager loading instead.
>

Hell yeah!


> Stored procs are best, of course, as it's often much easier to get stored
> proc changes through change control in enterprises than code changes in an
> app, which requires virtually a compete redeploy.
>

Mostly hell yeah, but it's double-edged sword. Procs are just scripts and
sloppy developers just change them willy-nillly and break things (how many
times have you seen that happen!?). You have to treat procs like code,
which is really hard as they live in different worlds. I'm suffering from
that at the moment in some hobby code, as I have a creepy feeling I never
know which copy of the proc source is the real one.

*GK*

RE: Entity Framework - the lay of the land

[罗格雷格博士]

“ORMs are still a real coding productivity boost,”

Are they though? I see them knock at best 10% off a dev project, and that dev 
work is at best probably 10% of the lifetime cost of the project.

So a 1% overall saving in project cost ends up determining and limiting so many 
aspects of the overall project over its life? Not sure that’s any sort of boost.

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://greglow.me

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Tuesday, 3 January 2017 8:16 PM
To: ozDotNet 
Subject: Re: Entity Framework - the lay of the land

Hi Grant et al,

You're psychic, as I was going to post on this old topic later in the week, as 
I've rejigged my thinking a little in recent months.

I also used CodeSmith to make CRUD for a few good years and I was impressed by 
how easy it was. I used the netTiers templates, not handmade. What I liked 
about netTiers was that the CRUD was basically table-based and not 
over-engineered like many famous ORMs (including EF) and it just threw a really 
handy bridge at the lowest useful level between classes and tables. Maybe even 
David C wouldn't turn his nose up at that?!

Both EF and netTiers support "deep loading" by effortlessly following joins, 
and that's about the only advanced feature of either of them that I ever used.

In recent months in both hobby code and some real apps I faced that choice of 
where to swing the pendulum of manipulating data ... towards the database or 
towards the app code. I have decided that all basic data manipulation like 
WHERE, ORDER, OVER, JOIN, SELECT, etc should be done in stored procs and not in 
the ORM or app code. You just can't beat the performance and clarity of doing 
this in the DB. After all, that's what it's built for! And EF is great for 
simply mapping the procs to methods and DTO classes.

I now put a fence up in my mind to put all basic data manipulation in the DB on 
one side and strictly business logic in the code on the other side. Sometimes 
you have to shred and knit DTOs, but that should be in app code as well.

And Grant's concern about dependency on specific ORMs is quite valid. We have 
one app that heavily used EF v4 and the self-tracking entities, which were 
deprecated, and now we're stuck and can't get to EF6 without industrial effort. 
Imagine trying to completely change your ORM brand.

So in summary I have decided for now that ORMs are still a real coding 
productivity boost, but only when used for basic CRUD and DTOs.

Greg K

Re: Entity Framework - the lay of the land

[Greg Keogh]

Hi Grant et al,

You're psychic, as I was going to post on this old topic later in the week,
as I've rejigged my thinking a little in recent months.

I also used CodeSmith to make CRUD for a few good years and I was impressed
by how easy it was. I used the netTiers templates, not handmade. What I
liked about netTiers was that the CRUD was basically table-based and not
over-engineered like many famous ORMs (including EF) and it just threw a
really handy bridge at the lowest useful level between classes and tables.
Maybe even David C wouldn't turn his nose up at that?!

Both EF and netTiers support "deep loading" by effortlessly following
joins, and that's about the only advanced feature of either of them that I
ever used.

In recent months in both hobby code and some real apps I faced that choice
of where to swing the pendulum of manipulating data ... towards the
database or towards the app code. I have decided that all basic data
manipulation like WHERE, ORDER, OVER, JOIN, SELECT, etc should be done in
stored procs and not in the ORM or app code. You just can't beat the
performance and clarity of doing this in the DB. After all, that's what
it's built for! And EF is great for simply mapping the procs to methods and
DTO classes.

I now put a fence up in my mind to put all basic data manipulation in the
DB on one side and strictly business logic in the code on the other side.
Sometimes you have to shred and knit DTOs, but that should be in app code
as well.

And Grant's concern about dependency on specific ORMs is quite valid. We
have one app that heavily used EF v4 and the self-tracking entities, which
were deprecated, and now we're stuck and can't get to EF6 without
industrial effort. Imagine trying to completely change your ORM brand.

So in summary I have decided for now that ORMs are still a real coding
productivity boost, but only when used for basic CRUD and DTOs.

*Greg K*

RE: Entity Framework - the lay of the land

[Tony Wright]

I often wish there was a better lightweight or that generated chide for you
from stored procs - dapper on steroids. Perhaps I should write one!

On 3 Jan 2017 5:31 PM, "Greg Low (罗格雷格博士)"  wrote:

> “ORMs are still a real coding productivity boost,”
>
>
>
> Are they though? I see them knock at best 10% off a dev project, and that
> dev work is at best probably 10% of the lifetime cost of the project.
>
>
>
> So a 1% overall saving in project cost ends up determining and limiting so
> many aspects of the overall project over its life? Not sure that’s any sort
> of boost.
>
>
>
> 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://greglow.me
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Greg Keogh
> *Sent:* Tuesday, 3 January 2017 8:16 PM
> *To:* ozDotNet 
> *Subject:* Re: Entity Framework - the lay of the land
>
>
>
> Hi Grant et al,
>
>
>
> You're psychic, as I was going to post on this old topic later in the
> week, as I've rejigged my thinking a little in recent months.
>
>
>
> I also used CodeSmith to make CRUD for a few good years and I was
> impressed by how easy it was. I used the netTiers templates, not handmade.
> What I liked about netTiers was that the CRUD was basically table-based and
> not over-engineered like many famous ORMs (including EF) and it just threw
> a really handy bridge at the lowest useful level between classes and
> tables. Maybe even David C wouldn't turn his nose up at that?!
>
>
>
> Both EF and netTiers support "deep loading" by effortlessly following
> joins, and that's about the only advanced feature of either of them that I
> ever used.
>
>
>
> In recent months in both hobby code and some real apps I faced that choice
> of where to swing the pendulum of manipulating data ... towards the
> database or towards the app code. I have decided that all basic data
> manipulation like WHERE, ORDER, OVER, JOIN, SELECT, etc should be done in
> stored procs and not in the ORM or app code. You just can't beat the
> performance and clarity of doing this in the DB. After all, that's what
> it's built for! And EF is great for simply mapping the procs to methods and
> DTO classes.
>
>
>
> I now put a fence up in my mind to put all basic data manipulation in the
> DB on one side and strictly business logic in the code on the other side.
> Sometimes you have to shred and knit DTOs, but that should be in app code
> as well.
>
>
>
> And Grant's concern about dependency on specific ORMs is quite valid. We
> have one app that heavily used EF v4 and the self-tracking entities, which
> were deprecated, and now we're stuck and can't get to EF6 without
> industrial effort. Imagine trying to completely change your ORM brand.
>
>
>
> So in summary I have decided for now that ORMs are still a real coding
> productivity boost, but only when used for basic CRUD and DTOs.
>
>
>
> *Greg K*
>

Re: Entity Framework - the lay of the land

[David Connors]

On Tue., 3 Jan. 2017, 8:07 pm David Connors,  wrote:

> On Tue., 3 Jan. 2017, 7:16 pm Greg Keogh,  wrote:
>
> Maybe even David C wouldn't turn his nose up at that?!
>
>
> I probably would. But I have a very different set of drivers to most
> everyobe else in this thread.
>

Except for Greg Low.


-- 
David Connors
da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363