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 (罗格雷格博士)" <g...@greglow.com> 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 <ozdotnet@ozdotnet.com>
> *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

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://www.sqldownunder.com/> | 
http://greglow.me<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 <ozdotnet@ozdotnet.com>
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, 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

[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

[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]

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

[Grant Maw]

ls and having our
> tools do good work.
>
> Enjoy your weekend all!
> --
> *From:* ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on
> behalf of Greg Low (罗格雷格博士) <g...@greglow.com>
> *Sent:* Saturday, 17 September 2016 9:03:49 AM
> *To:* ozDotNet
> *Subject:* RE: Entity Framework - the lay of the land
>
>
> Hey Dave and all,
>
>
>
> “The great” -> hardly but thanks Dave.
>
>
>
> Look, my issues with many of these ORMs are many. Unfortunately, I spend
> my life on the back end of trying to deal with the messes involved. The
> following are the key issues that I see:
>
>
>
> *Potentially horrid performance*
>
>
>
> I’ve been on the back end of this all the time. There are several reasons.
> One is that the frameworks generate horrid code to start with, the second
> is that they are typically quite resistant to improvement, the third is
> that they tend to encourage processing with far too much data movement.
>
>
>
> I regularly end up in software houses with major issues that they don’t
> know how to solve. As an example, I was at a start-up software house
> recently. They had had a team of 10 developers building an application for
> the last four years. The business owner said that if it would support 1000
> concurrent users, they would have a viable business. 5000 would make a good
> business. 500 they might survive. They had their first serious performance
> test two weeks before they had to show the investors. It fell over with 9
> concurrent users. The management (and in this case the devs too) were
> panic-stricken.
>
>
>
> Another recent example was a software house that had to deliver an app to
> a government department. They were already 4 weeks overdue and couldn’t get
> it out of UAT. They wanted a silver bullet. That’s not the point to then be
> discussing their architectural decisions yet they were the issue.
>
>
>
> I was in a large financial in Sydney a while back. They were in the middle
> of removing the ORM that they’d chosen out of their app because try as they
> might, they couldn’t get anywhere near the required performance numbers.
> Why had they called me in? Because before they wrote off 8 months’ work for
> 240 developers, the management wanted another opinion.
>
>
>
> Just yesterday I was working on a background processing job that processes
> a certain type of share trades in a UK-based financial service
> organisation. On a system with 48 processors, and 1.2 TB of memory, and 7 x
> 1 million UK pound 20TB flash drive arrays, it ran for 48 minutes. During
> that time, it issued 550 million SQL batches to be processed and almost
> nothing else would work well on the machine at the same time. The
> replacement job that we wrote in T-SQL issued 40,000 SQL batches and ran in
> just over 2 minutes. I think I can get that to 1/10 of that with further
> work. Guess which version is likely to get used now?
>
>
>
> *Minimal savings yet long term pain*
>
>
>
> Many of the ORMs give you an initial boost to “getting something done”.
> But at what cost? At best, on most projects that I see, it might save 10%
> of the original development time, on the first project. But as David
> pointed out in his excellent TechEd talk with Joel (and as I’ve seen from
> so many other places), the initial development cost of a project is usually
> only around 10% of the overall development cost. So what are we talking
> about? Perhaps 1% of the whole project? Putting yourself into a long-term
> restrictive straightjacket situation for the sake of a 1% saving is a big,
> big call. The problem is that it’s being decided by someone who isn’t
> looking at the lifetime cost, and often 90% of that lifetime cost comes out
> of someone else’s bucket.
>
>
>
> *Getting stuck in how it works*
>
>
>
> For years, code generated by tools like Linq to SQL was very poor. And it
> knew it was talking to SQL Server in the first place. Now imagine that
> you’re generating code and you don’t even know what the DB is. That’s where
> EF started. Very poor choices are often made in these tools. The whole
> reason that “optimize for ad hoc workloads” was added to SQL Server was to
> deal with the mess from the plan cache pollution caused by these tools. A
> simple example is that on the SqlCommand object, they called AddWithValue()
> to add parameters to the parameters collection. That’s a really bad idea.
> It provides the name of the parameter and the value, but no data type. So
> it used to try to derive the data type from the data. So SQL Server would
> end up with a separate query plan for every combination of every length of
> string for every parameter. And what

Re: Entity Framework - the lay of the land

[Joseph Cooney]

Preach on.

On 16 Sep. 2016 10:50 am, "David Connors"  wrote:

> On Fri, 16 Sep 2016 at 10:33 Greg Keogh  wrote:
>
>> What do you suggest as an alternative?
>>>
>>> Writing stored procedures.
>>>
>>
>> What about the classical problem of "impedance mismatch". You have to
>> carefully maintain DataSets or similar and use DataAdapter to fill them,
>> then writing data back is a circus trick with the ADO.NET classes.
>>
>
> Otherwise referred to as doing high quality work.
>
>
>> Then they invented ORMs, why did they do that!? -- *GK*
>>
>
> I have given this considerable thought over the years. Normally I explain
> this with swear words but I think it boils down to two key factors.
>
> *Weltanschauung*
> The people who think that ORMs are a good idea have a code-centric view of
> the world. Careful declarative design of a data tier is outside of this
> world-view so they see it as overhead (plus they often have to bargain with
> smelly neck beard DBAs).
>
> *Free Lunch / Laziness / Lack of care for end result*
> Developers get excited over the prospect of auto-generation because OMFG
> look at all that code I did not write actually. Most developers don't wear
> the ops cost of their solutions and they certainly don't USE them and
> consequently don't give a toss if some EF-based turd they engineered takes
> 10 seconds to do things that should take 10msec.
>
> Things would be different if the average engineer were forced to walk a
> mile in the average IT pro / end users shoes.
>
> YMMV but I had a good rant on this a few years back:
> https://www.youtube.com/watch?v=YMfRahO8fLo (jesus that was 6 years ago).
> I have softened my stance on Agile somewhat since then.
>
> Good outcomes always take more effort and energy. The universe has been
> that way for 13.8 billion years and isn't going to change any time soon.
>
> David.
>
> --
> David Connors
> da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363
>

Re: Entity Framework - the lay of the land

[Stephen Price]

Hehe, I get a sense that was Greg laughing and pointing...  []


Well, I must say I've had a win. As with most of these things it was performing 
poorly because of my code.


I understand how IQueryable works versues IEnumerable, and I was modifying the 
object which I thought was queryable along the way. Kind of building up the 
filters I needed then sending the lot to the server to do.

Something that was puzzling me was that .Take(100) was not ending up as a TOP 
100 in my query. Should have told me something was wrong when I was seeing 
unexpected query. Turns out I was storing my IQueryable object in a LIST.

So as soon as something accessed the list it would send it to the SQL server 
and all the rest worked but was being done in memory on a lot more data than I 
wanted.

Changed this line;

IEnumerable results = new List();

into this one

IQueryable results = null;

and then it stays queryable all the way to very end. Now I see MAX, and TOP 100 
and all the other things I was expecting in my SQL and the 40 second query now 
takes 12 seconds.

I think I'm happy with that.

Big thanks to the comments. Lesson learned, be careful where you put your query 
before you've finished with it. Premature evaluation.


cheers

Stephen


From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on behalf 
of Greg Low (罗格雷格博士) <g...@greglow.com>
Sent: Tuesday, 4 October 2016 11:22:41 AM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land

There is a certain sweet irony in creating a SQL object to query, to get around 
a limitation of querying the actual SQL object using the framework no ?

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 Corneliu I. Tusnea
Sent: Tuesday, 4 October 2016 12:36 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

Stephen,

My 2 cents without seeing the query.
1. Try to make a view that groups your main table with the detail table to 
calculate that extra status field.
I'd expect that to be quick and easy to do.
2. Change your EF to not query the table + 100 queries for the status but query 
the view.




On Tue, Oct 4, 2016 at 12:29 PM, Stephen Price 
<step...@lythixdesigns.com<mailto:step...@lythixdesigns.com>> wrote:

Hey all,



Am looking at optimising an EF query right now, so thought it would be ok to 
hijack this thread. Even if it leads to bagging of EF, I'm ok with that. []



So I have a single table being queried, and I grabbed the query being run via 
SQL Server profiler.

4.5million records in the table. Have an Id field, a year field and an EventId 
field. The rest of the fields are data, so not searching those.

The query being produced is  showing as an sp_execsql and does a where against 
the year field.

The actual query itself takes 1699ms, but the screen takes longer to return the 
result as it then loads the detail of each item so it can show the current 
status of each row. (ie the highest version status is the current, in a related 
status table).

So each query is fast but by the time it loads 100 of them, its made 100 little 
calls which all add up to a long delay to the user.



Options I'm thinking here (looking for validation of my thinking, or new ideas 
outside my database knowledge)

1. Reduce the number of items. Say 20 instead of 100.

2. Get the Status asyncronously. Would need to work out how to do that client 
side but seems viable. Initial list would load in 2 seconds, then statuses at 
the top would load almost right away. Items out of sight (scroll to view them) 
would load later.

3. Single query. Server side query is doing a take(100) to reduce the number of 
results if the search is too broad... which means its possibly prematurely 
resolving the linq query and sending the status lookups individually rather 
than single query.

4. something else. Get rid of EF and hand write SQL. Look for new job because 
didn't deliver on time. []



Feedback, criticism, laughing and pointing all welcomed.

cheers

Stephen


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
<ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>> on behalf 
of Kirsten Greed <kirst...@jobtalk.com.au<mailto:kirst...@jobtalk.com.au>>
Sent: Saturday, 1 October 2016 5:26:33 PM

To: 'ozDotNet'
Subject: RE: Entity Framework - the lay of the land

That makes sense

It would be good to have some guidelines about where the cut over point is.

Also whether solutions like NService Bus could mitigate the use of EF ?



From: ozdotnet-boun...@ozdotnet.com<m

RE: Entity Framework - the lay of the land

[Tony Wright]

Shouldn't need to. Either join to the table in your Linq that contains the
status and make sure it's "Include"d when the l in is executed.
Alternatively, perhaps a calculated field in entity framework itself?

On 4 Oct 2016 2:22 PM, "Greg Low (罗格雷格博士)" <g...@greglow.com> wrote:

> There is a certain sweet irony in creating a SQL object to query, to get
> around a limitation of querying the actual SQL object using the framework
> no ?
>
>
>
> 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 *Corneliu I. Tusnea
> *Sent:* Tuesday, 4 October 2016 12:36 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Entity Framework - the lay of the land
>
>
>
> Stephen,
>
>
>
> My 2 cents without seeing the query.
>
> 1. Try to make a view that groups your main table with the detail table to
> calculate that extra status field.
>
> I'd expect that to be quick and easy to do.
>
> 2. Change your EF to not query the table + 100 queries for the status but
> query the view.
>
>
>
>
>
>
>
>
>
> On Tue, Oct 4, 2016 at 12:29 PM, Stephen Price <step...@lythixdesigns.com>
> wrote:
>
> Hey all,
>
>
>
> Am looking at optimising an EF query right now, so thought it would be ok
> to hijack this thread. Even if it leads to bagging of EF, I'm ok with that. 
> [image:
> ]
>
>
>
> So I have a single table being queried, and I grabbed the query being run
> via SQL Server profiler.
>
> 4.5million records in the table. Have an Id field, a year field and an
> EventId field. The rest of the fields are data, so not searching those.
>
> The query being produced is  showing as an sp_execsql and does a where
> against the year field.
>
> The actual query itself takes 1699ms, but the screen takes longer to
> return the result as it then loads the detail of each item so it can show
> the current status of each row. (ie the highest version status is the
> current, in a related status table).
>
> So each query is fast but by the time it loads 100 of them, its made 100
> little calls which all add up to a long delay to the user.
>
>
>
> Options I'm thinking here (looking for validation of my thinking, or new
> ideas outside my database knowledge)
>
> 1. Reduce the number of items. Say 20 instead of 100.
>
> 2. Get the Status asyncronously. Would need to work out how to do that
> client side but seems viable. Initial list would load in 2 seconds, then
> statuses at the top would load almost right away. Items out of sight
> (scroll to view them) would load later.
>
> 3. Single query. Server side query is doing a take(100) to reduce the
> number of results if the search is too broad... which means its possibly
> prematurely resolving the linq query and sending the status lookups
> individually rather than single query.
>
> 4. something else. Get rid of EF and hand write SQL. Look for new job
> because didn't deliver on time. [image: ]
>
>
>
> Feedback, criticism, laughing and pointing all welcomed.
>
> cheers
>
> Stephen
> --
>
> *From:* ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on
> behalf of Kirsten Greed <kirst...@jobtalk.com.au>
> *Sent:* Saturday, 1 October 2016 5:26:33 PM
>
>
> *To:* 'ozDotNet'
> *Subject:* RE: Entity Framework - the lay of the land
>
>
>
> That makes sense
>
>
>
> It would be good to have some guidelines about where the cut over point is.
>
>
>
> Also whether solutions like NService Bus could mitigate the use of EF ?
>
>
>
> --
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Greg Low (??)
> *Sent:* Saturday, 1 October 2016 12:40 PM
> *To:* ozDotNet
> *Subject:* RE: Entity Framework - the lay of the land
>
> Agreed but not websites with thousands of concurrent users. The problem is
> that people don’t realise that the same logic doesn’t apply in both areas.
>
>
>
> 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 *Kirsten Greed
> *Sent:* Satu

RE: Entity Framework - the lay of the land

[罗格雷格博士]

There is a certain sweet irony in creating a SQL object to query, to get around 
a limitation of querying the actual SQL object using the framework no ?

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 Corneliu I. Tusnea
Sent: Tuesday, 4 October 2016 12:36 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

Stephen,

My 2 cents without seeing the query.
1. Try to make a view that groups your main table with the detail table to 
calculate that extra status field.
I'd expect that to be quick and easy to do.
2. Change your EF to not query the table + 100 queries for the status but query 
the view.




On Tue, Oct 4, 2016 at 12:29 PM, Stephen Price 
<step...@lythixdesigns.com<mailto:step...@lythixdesigns.com>> wrote:

Hey all,



Am looking at optimising an EF query right now, so thought it would be ok to 
hijack this thread. Even if it leads to bagging of EF, I'm ok with that. []



So I have a single table being queried, and I grabbed the query being run via 
SQL Server profiler.

4.5million records in the table. Have an Id field, a year field and an EventId 
field. The rest of the fields are data, so not searching those.

The query being produced is  showing as an sp_execsql and does a where against 
the year field.

The actual query itself takes 1699ms, but the screen takes longer to return the 
result as it then loads the detail of each item so it can show the current 
status of each row. (ie the highest version status is the current, in a related 
status table).

So each query is fast but by the time it loads 100 of them, its made 100 little 
calls which all add up to a long delay to the user.



Options I'm thinking here (looking for validation of my thinking, or new ideas 
outside my database knowledge)

1. Reduce the number of items. Say 20 instead of 100.

2. Get the Status asyncronously. Would need to work out how to do that client 
side but seems viable. Initial list would load in 2 seconds, then statuses at 
the top would load almost right away. Items out of sight (scroll to view them) 
would load later.

3. Single query. Server side query is doing a take(100) to reduce the number of 
results if the search is too broad... which means its possibly prematurely 
resolving the linq query and sending the status lookups individually rather 
than single query.

4. something else. Get rid of EF and hand write SQL. Look for new job because 
didn't deliver on time. []



Feedback, criticism, laughing and pointing all welcomed.

cheers

Stephen


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
<ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>> on behalf 
of Kirsten Greed <kirst...@jobtalk.com.au<mailto:kirst...@jobtalk.com.au>>
Sent: Saturday, 1 October 2016 5:26:33 PM

To: 'ozDotNet'
Subject: RE: Entity Framework - the lay of the land

That makes sense

It would be good to have some guidelines about where the cut over point is.

Also whether solutions like NService Bus could mitigate the use of EF ?



From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Greg Low (??)
Sent: Saturday, 1 October 2016 12:40 PM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land
Agreed but not websites with thousands of concurrent users. The problem is that 
people don’t realise that the same logic doesn’t apply in both areas.

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410<tel:%2B61%20419201410> mobile│ 
+61 3 8676 4913<tel:%2B61%203%208676%204913> 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> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:42 AM
To: 'ozDotNet' <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Entity Framework - the lay of the land

Caveat: this is for winforms line of business applications.



From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:35 AM
To: 'ozDotNet'
Subject: Entity Framework - the lay of the land
My 2c

Horses for courses

I am using  EF Code first and loving it.

Most of the posts on this thread a

Re: Entity Framework - the lay of the land

[Stephen Price]

Yep, was also considering a view or a join, with the goal to be getting all of 
the results in a single query.


Will try the join first in code, but right now the view is sounding like the 
option I'll end up going with.


thanks for the replies!


From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on behalf 
of Corneliu I. Tusnea <corne...@acorns.com.au>
Sent: Tuesday, 4 October 2016 9:36:09 AM
To: ozDotNet
Subject: Re: Entity Framework - the lay of the land

Stephen,

My 2 cents without seeing the query.
1. Try to make a view that groups your main table with the detail table to 
calculate that extra status field.
I'd expect that to be quick and easy to do.
2. Change your EF to not query the table + 100 queries for the status but query 
the view.




On Tue, Oct 4, 2016 at 12:29 PM, Stephen Price 
<step...@lythixdesigns.com<mailto:step...@lythixdesigns.com>> wrote:

Hey all,


Am looking at optimising an EF query right now, so thought it would be ok to 
hijack this thread. Even if it leads to bagging of EF, I'm ok with that. []


So I have a single table being queried, and I grabbed the query being run via 
SQL Server profiler.

4.5million records in the table. Have an Id field, a year field and an EventId 
field. The rest of the fields are data, so not searching those.

The query being produced is  showing as an sp_execsql and does a where against 
the year field.

The actual query itself takes 1699ms, but the screen takes longer to return the 
result as it then loads the detail of each item so it can show the current 
status of each row. (ie the highest version status is the current, in a related 
status table).

So each query is fast but by the time it loads 100 of them, its made 100 little 
calls which all add up to a long delay to the user.


Options I'm thinking here (looking for validation of my thinking, or new ideas 
outside my database knowledge)

1. Reduce the number of items. Say 20 instead of 100.

2. Get the Status asyncronously. Would need to work out how to do that client 
side but seems viable. Initial list would load in 2 seconds, then statuses at 
the top would load almost right away. Items out of sight (scroll to view them) 
would load later.

3. Single query. Server side query is doing a take(100) to reduce the number of 
results if the search is too broad... which means its possibly prematurely 
resolving the linq query and sending the status lookups individually rather 
than single query.

4. something else. Get rid of EF and hand write SQL. Look for new job because 
didn't deliver on time. []


Feedback, criticism, laughing and pointing all welcomed.

cheers

Stephen


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
<ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>> on behalf 
of Kirsten Greed <kirst...@jobtalk.com.au<mailto:kirst...@jobtalk.com.au>>
Sent: Saturday, 1 October 2016 5:26:33 PM

To: 'ozDotNet'
Subject: RE: Entity Framework - the lay of the land

That makes sense

It would be good to have some guidelines about where the cut over point is.

Also whether solutions like NService Bus could mitigate the use of EF ?



From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Greg Low (??)
Sent: Saturday, 1 October 2016 12:40 PM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land

Agreed but not websites with thousands of concurrent users. The problem is that 
people don’t realise that the same logic doesn’t apply in both areas.

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410<tel:%2B61%20419201410> mobile│ 
+61 3 8676 4913<tel:%2B61%203%208676%204913> 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> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:42 AM
To: 'ozDotNet' <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Entity Framework - the lay of the land

Caveat: this is for winforms line of business applications.



From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:35 AM
To: 'ozDotNet'
Subject: Entity Framework - the lay of the land
My 2c

Horses for courses

I am using  EF Code first and loving it.

Most of the posts on this thread are about building the thing right.

Yet I am finding that EF Code first helps me a lot with building the right 

Re: Entity Framework - the lay of the land

[Craig van Nieuwkerk]

This is a standard N+1 problem that ORM's are so good at it. It often
raises it's head when developers develop against small amounts of data and
runs fast but in production runs like a dog. It sounds like you should be
able to do it in a single query, I am not sure about EF but with NHibernate
would be fairly easy. SQL would be trivial.


On Tue, Oct 4, 2016 at 12:29 PM, Stephen Price <step...@lythixdesigns.com>
wrote:

> Hey all,
>
>
> Am looking at optimising an EF query right now, so thought it would be ok
> to hijack this thread. Even if it leads to bagging of EF, I'm ok with that. 
> [image:
> ]
>
>
> So I have a single table being queried, and I grabbed the query being run
> via SQL Server profiler.
>
> 4.5million records in the table. Have an Id field, a year field and an
> EventId field. The rest of the fields are data, so not searching those.
>
> The query being produced is  showing as an sp_execsql and does a where
> against the year field.
>
> The actual query itself takes 1699ms, but the screen takes longer to
> return the result as it then loads the detail of each item so it can show
> the current status of each row. (ie the highest version status is the
> current, in a related status table).
>
> So each query is fast but by the time it loads 100 of them, its made 100
> little calls which all add up to a long delay to the user.
>
>
> Options I'm thinking here (looking for validation of my thinking, or new
> ideas outside my database knowledge)
>
> 1. Reduce the number of items. Say 20 instead of 100.
>
> 2. Get the Status asyncronously. Would need to work out how to do that
> client side but seems viable. Initial list would load in 2 seconds, then
> statuses at the top would load almost right away. Items out of sight
> (scroll to view them) would load later.
>
> 3. Single query. Server side query is doing a take(100) to reduce the
> number of results if the search is too broad... which means its possibly
> prematurely resolving the linq query and sending the status lookups
> individually rather than single query.
>
> 4. something else. Get rid of EF and hand write SQL. Look for new job
> because didn't deliver on time. [image: ]
>
>
> Feedback, criticism, laughing and pointing all welcomed.
>
> cheers
>
> Stephen
> --
> *From:* ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on
> behalf of Kirsten Greed <kirst...@jobtalk.com.au>
> *Sent:* Saturday, 1 October 2016 5:26:33 PM
>
> *To:* 'ozDotNet'
> *Subject:* RE: Entity Framework - the lay of the land
>
> That makes sense
>
> It would be good to have some guidelines about where the cut over point is.
>
> Also whether solutions like NService Bus could mitigate the use of EF ?
>
>
> --------------
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Greg Low (??)
> *Sent:* Saturday, 1 October 2016 12:40 PM
> *To:* ozDotNet
> *Subject:* RE: Entity Framework - the lay of the land
>
> Agreed but not websites with thousands of concurrent users. The problem is
> that people don’t realise that the same logic doesn’t apply in both areas.
>
>
>
> 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 *Kirsten Greed
> *Sent:* Saturday, 1 October 2016 6:42 AM
> *To:* 'ozDotNet' <ozdotnet@ozdotnet.com>
> *Subject:* RE: Entity Framework - the lay of the land
>
>
>
> Caveat: this is for winforms line of business applications.
>
>
>
>
> --
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com <ozdotnet-boun...@ozdotnet.com>] *On Behalf Of *Kirsten Greed
> *Sent:* Saturday, 1 October 2016 6:35 AM
> *To:* 'ozDotNet'
> *Subject:* Entity Framework - the lay of the land
>
> My 2c
>
>
>
> Horses for courses
>
>
>
> I am using  EF Code first and loving it.
>
>
>
> Most of the posts on this thread are about *building the thing right*.
>
>
>
> Yet I am finding that EF Code first helps me a lot with *building the
> right thing.*
>
>
>
> I find changing the database design is much easier now that I use EF
> Migrations, this helps me stay in a "play" headset, lowering my fear of
> changing the database structure.
>
>
>
> There are places where I choose to break into transact-sql, but most of my
>

Re: Entity Framework - the lay of the land

[Corneliu I. Tusnea]

Stephen,

My 2 cents without seeing the query.
1. Try to make a view that groups your main table with the detail table to
calculate that extra status field.
I'd expect that to be quick and easy to do.
2. Change your EF to not query the table + 100 queries for the status but
query the view.




On Tue, Oct 4, 2016 at 12:29 PM, Stephen Price <step...@lythixdesigns.com>
wrote:

> Hey all,
>
>
> Am looking at optimising an EF query right now, so thought it would be ok
> to hijack this thread. Even if it leads to bagging of EF, I'm ok with that. 
> [image:
> ]
>
>
> So I have a single table being queried, and I grabbed the query being run
> via SQL Server profiler.
>
> 4.5million records in the table. Have an Id field, a year field and an
> EventId field. The rest of the fields are data, so not searching those.
>
> The query being produced is  showing as an sp_execsql and does a where
> against the year field.
>
> The actual query itself takes 1699ms, but the screen takes longer to
> return the result as it then loads the detail of each item so it can show
> the current status of each row. (ie the highest version status is the
> current, in a related status table).
>
> So each query is fast but by the time it loads 100 of them, its made 100
> little calls which all add up to a long delay to the user.
>
>
> Options I'm thinking here (looking for validation of my thinking, or new
> ideas outside my database knowledge)
>
> 1. Reduce the number of items. Say 20 instead of 100.
>
> 2. Get the Status asyncronously. Would need to work out how to do that
> client side but seems viable. Initial list would load in 2 seconds, then
> statuses at the top would load almost right away. Items out of sight
> (scroll to view them) would load later.
>
> 3. Single query. Server side query is doing a take(100) to reduce the
> number of results if the search is too broad... which means its possibly
> prematurely resolving the linq query and sending the status lookups
> individually rather than single query.
>
> 4. something else. Get rid of EF and hand write SQL. Look for new job
> because didn't deliver on time. [image: ]
>
>
> Feedback, criticism, laughing and pointing all welcomed.
>
> cheers
>
> Stephen
> --
> *From:* ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on
> behalf of Kirsten Greed <kirst...@jobtalk.com.au>
> *Sent:* Saturday, 1 October 2016 5:26:33 PM
>
> *To:* 'ozDotNet'
> *Subject:* RE: Entity Framework - the lay of the land
>
> That makes sense
>
> It would be good to have some guidelines about where the cut over point is.
>
> Also whether solutions like NService Bus could mitigate the use of EF ?
>
>
> --------------
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Greg Low (??)
> *Sent:* Saturday, 1 October 2016 12:40 PM
> *To:* ozDotNet
> *Subject:* RE: Entity Framework - the lay of the land
>
> Agreed but not websites with thousands of concurrent users. The problem is
> that people don’t realise that the same logic doesn’t apply in both areas.
>
>
>
> 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 *Kirsten Greed
> *Sent:* Saturday, 1 October 2016 6:42 AM
> *To:* 'ozDotNet' <ozdotnet@ozdotnet.com>
> *Subject:* RE: Entity Framework - the lay of the land
>
>
>
> Caveat: this is for winforms line of business applications.
>
>
>
>
> --
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com <ozdotnet-boun...@ozdotnet.com>] *On Behalf Of *Kirsten Greed
> *Sent:* Saturday, 1 October 2016 6:35 AM
> *To:* 'ozDotNet'
> *Subject:* Entity Framework - the lay of the land
>
> My 2c
>
>
>
> Horses for courses
>
>
>
> I am using  EF Code first and loving it.
>
>
>
> Most of the posts on this thread are about *building the thing right*.
>
>
>
> Yet I am finding that EF Code first helps me a lot with *building the
> right thing.*
>
>
>
> I find changing the database design is much easier now that I use EF
> Migrations, this helps me stay in a "play" headset, lowering my fear of
> changing the database structure.
>
>
>
> There are places where I choose to break into transact-sql, but most of my
> CRUD is done via DevExpress XAF with EF Code first.
>
>
>
> My 2c :-)
>
> Kirsten
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> __ Information from ESET NOD32 Antivirus, version of virus
> signature database 14206 (20160930) __
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> __ Information from ESET NOD32 Antivirus, version of virus
> signature database 14208 (20161001) __
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>

Re: Entity Framework - the lay of the land

[Stephen Price]

Hey all,


Am looking at optimising an EF query right now, so thought it would be ok to 
hijack this thread. Even if it leads to bagging of EF, I'm ok with that. []


So I have a single table being queried, and I grabbed the query being run via 
SQL Server profiler.

4.5million records in the table. Have an Id field, a year field and an EventId 
field. The rest of the fields are data, so not searching those.

The query being produced is  showing as an sp_execsql and does a where against 
the year field.

The actual query itself takes 1699ms, but the screen takes longer to return the 
result as it then loads the detail of each item so it can show the current 
status of each row. (ie the highest version status is the current, in a related 
status table).

So each query is fast but by the time it loads 100 of them, its made 100 little 
calls which all add up to a long delay to the user.


Options I'm thinking here (looking for validation of my thinking, or new ideas 
outside my database knowledge)

1. Reduce the number of items. Say 20 instead of 100.

2. Get the Status asyncronously. Would need to work out how to do that client 
side but seems viable. Initial list would load in 2 seconds, then statuses at 
the top would load almost right away. Items out of sight (scroll to view them) 
would load later.

3. Single query. Server side query is doing a take(100) to reduce the number of 
results if the search is too broad... which means its possibly prematurely 
resolving the linq query and sending the status lookups individually rather 
than single query.

4. something else. Get rid of EF and hand write SQL. Look for new job because 
didn't deliver on time. []


Feedback, criticism, laughing and pointing all welcomed.

cheers

Stephen


From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on behalf 
of Kirsten Greed <kirst...@jobtalk.com.au>
Sent: Saturday, 1 October 2016 5:26:33 PM
To: 'ozDotNet'
Subject: RE: Entity Framework - the lay of the land

That makes sense

It would be good to have some guidelines about where the cut over point is.

Also whether solutions like NService Bus could mitigate the use of EF ?



From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low (??)
Sent: Saturday, 1 October 2016 12:40 PM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land

Agreed but not websites with thousands of concurrent users. The problem is that 
people don’t realise that the same logic doesn’t apply in both areas.

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 Kirsten Greed
Sent: Saturday, 1 October 2016 6:42 AM
To: 'ozDotNet' <ozdotnet@ozdotnet.com>
Subject: RE: Entity Framework - the lay of the land

Caveat: this is for winforms line of business applications.



From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:35 AM
To: 'ozDotNet'
Subject: Entity Framework - the lay of the land
My 2c

Horses for courses

I am using  EF Code first and loving it.

Most of the posts on this thread are about building the thing right.

Yet I am finding that EF Code first helps me a lot with building the right 
thing.

I find changing the database design is much easier now that I use EF 
Migrations, this helps me stay in a "play" headset, lowering my fear of 
changing the database structure.

There are places where I choose to break into transact-sql, but most of my CRUD 
is done via DevExpress XAF with EF Code first.

My 2c :-)
Kirsten












__ Information from ESET NOD32 Antivirus, version of virus signature 
database 14206 (20160930) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 14208 (20161001) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: Entity Framework - the lay of the land

[Kirsten Greed]

That makes sense
 
It would be good to have some guidelines about where the cut over point is.
 
Also whether solutions like NService Bus could mitigate the use of EF ?

 
  _  

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Greg Low (??)
Sent: Saturday, 1 October 2016 12:40 PM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land



Agreed but not websites with thousands of concurrent users. The problem is
that people don't realise that the same logic doesn't apply in both areas.

 

Regards,

 

Greg

 

Dr Greg Low

 

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax


SQL Down Under | Web:  <http://www.sqldownunder.com/> www.sqldownunder.com |
<http://greglow.me/> http://greglow.me

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:42 AM
To: 'ozDotNet' <ozdotnet@ozdotnet.com>
Subject: RE: Entity Framework - the lay of the land

 

Caveat: this is for winforms line of business applications.

 

 

  _  

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:35 AM
To: 'ozDotNet'
Subject: Entity Framework - the lay of the land

My 2c

 

Horses for courses

 

I am using  EF Code first and loving it.

 

Most of the posts on this thread are about building the thing right.

 

Yet I am finding that EF Code first helps me a lot with building the right
thing.

 

I find changing the database design is much easier now that I use EF
Migrations, this helps me stay in a "play" headset, lowering my fear of
changing the database structure.

 

There are places where I choose to break into transact-sql, but most of my
CRUD is done via DevExpress XAF with EF Code first.

 

My 2c :-)

Kirsten

 

 

 

 

 

 

 

 

 

 



__ Information from ESET NOD32 Antivirus, version of virus signature
database 14206 (20160930) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__ Information from ESET NOD32 Antivirus, version of virus signature
database 14208 (20161001) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: Entity Framework - the lay of the land

[罗格雷格博士]

Agreed but not websites with thousands of concurrent users. The problem is that 
people don’t realise that the same logic doesn’t apply in both areas.

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 Kirsten Greed
Sent: Saturday, 1 October 2016 6:42 AM
To: 'ozDotNet' <ozdotnet@ozdotnet.com>
Subject: RE: Entity Framework - the lay of the land

Caveat: this is for winforms line of business applications.



From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:35 AM
To: 'ozDotNet'
Subject: Entity Framework - the lay of the land
My 2c

Horses for courses

I am using  EF Code first and loving it.

Most of the posts on this thread are about building the thing right.

Yet I am finding that EF Code first helps me a lot with building the right 
thing.

I find changing the database design is much easier now that I use EF 
Migrations, this helps me stay in a "play" headset, lowering my fear of 
changing the database structure.

There are places where I choose to break into transact-sql, but most of my CRUD 
is done via DevExpress XAF with EF Code first.

My 2c :-)
Kirsten












__ Information from ESET NOD32 Antivirus, version of virus signature 
database 14206 (20160930) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: Entity Framework - the lay of the land

[Kirsten Greed]

Caveat: this is for winforms line of business applications.
 

  _  

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Kirsten Greed
Sent: Saturday, 1 October 2016 6:35 AM
To: 'ozDotNet'
Subject: Entity Framework - the lay of the land


My 2c
 
Horses for courses
 
I am using  EF Code first and loving it.
 
Most of the posts on this thread are about building the thing right.
 
Yet I am finding that EF Code first helps me a lot with building the right
thing.
 
I find changing the database design is much easier now that I use EF
Migrations, this helps me stay in a "play" headset, lowering my fear of
changing the database structure.
 
There are places where I choose to break into transact-sql, but most of my
CRUD is done via DevExpress XAF with EF Code first.
 
My 2c :-)
Kirsten
 
 
 
 
 
 
 
 
 
 


__ Information from ESET NOD32 Antivirus, version of virus signature
database 14206 (20160930) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: Entity Framework - the lay of the land

[罗格雷格博士]

We often rewrite the queries to use TVFs instead

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




On Wed, Sep 21, 2016 at 10:35 PM +1000, "David Rhys Jones" 
> wrote:

>> SQL Functions suck. Oh my, they suck and they are hard to fix and cumbersome 
>> to figure out where perf is bad.

I agree, don't use SQL functions in where clauses, joins or aggregates.  It's 
ok to use if you have a small dataset but otherwise  steer clear.

Davy


Si hoc legere scis nimium eruditionis habes.


On Wed, Sep 21, 2016 at 2:22 PM, Corneliu I. Tusnea 
> wrote:
I'll jump in with my experience (just last year).
Using EF7 (EF Core 1.0 now?)

I always disliked EF version but I liked the original Linq2Sql which was quite 
lightweight compared to EF.

  1.  Database design and DTO design is very very strictly monitored and 
mapping Table > Entity is very strict with only the exact fields required.
  2.  I find EF perfect for most simple reads of data as long as I don't have 
to join or simple very exact joins. Yes, I know Dapper and PetaPoco but heck, I 
really don't want to maintain strings.
  3.  Views rule. Whenever we need more complicated data we do it in a view. We 
can review, optimize and tweak that as needed.
  4.  SPs rock. Same as above, any work that can be moved in an SP is done in 
an SP (very few scenarios in our case)
  5.  SQL Functions suck. Oh my, they suck and they are hard to fix and 
cumbersome to figure out where perf is bad.
  6.  And most importantly. SQL is long-term-storage NOT the source of truth. 
We use Akka and we (now) consider SQL as eventual storage of data. Everything 
we do is in memory and whenever we have a chance we'll tell SQL about it 
(mostly so after a restart we can start with the data from SQL). You want to 
save some settings? Sure, it's in memory and hey sql, here is an update. Want 
to read a setting? It's in memory no need to ask SQL about it.

I think EF7 (as I said previous versions were garbage), like every other 
technology can be abused.
The problem is that it can be abused way to easily.
Teams use it and abuse it instead of understanding the synergy that needs to 
exist and where the power EF offers should be used.

My 2 cents,
Corneliu.







On Tue, Sep 20, 2016 at 9:06 PM, Tony McGee 
> wrote:
Oh boy, this is a technique I see way underutilised when using EF:
  All objects from EF were transformed into new objects for use in the website

e.g. If I just want a high level list of the product categories a customer has 
purchased, it's far too easily get stuck in a rigid thought pattern due to the 
object model. It says I need a Customer that has an Orders collection each 
having a set of Line Items, dollar values, quantities, special delivery 
instructions, product names, descriptions, packaging dimensions, blah, blah, 
blah NO.
Bringing the whole database across the wire and aggregating in application 
memory is inviting a world of pain.

An EF query projection containing the customer id/name and product category 
name could avoid a huge complicated SELECT * across six different table joins 
that becomes impossible to index.




On 20/09/2016 19:20, David Rhys Jones wrote:

I've been working with EF now for a few years,  here's a list of what went 
wrong / what went right.

Large public Website

Good:
No complex queries in EF, anything more than a couple of tables and a 
stored procedure is called.
All objects from EF were transformed into new objects for use in the website
Bad:
   The context was shared between processes and thusly began to grow after an 
hour or two, causing a slowdown of EF. Regular flushing solved this
  Updates into the database set the FK property but did not attach the object, 
this resulted in data being correct for a moment, but then overwritten with the 
original values when the savechanges was called.


Large Multinational Bank - Bulk Processing
   Good:
   Most processing was done without EF,
  The website used EF to query the same data.
   Bad:
   Framework implemented IEnumerable as each interface, thus   
service.GetClients().Count()  resulted in the entire table being returned. 
Changing the interface to IQueryable allowed the DB to do a count(*)

Large Multinational,  low use public website.
   Good:
  EF context is queried and disposed of as soon as possible, leaving the 
website responsive
   Bad:
 Bad design of the database has resulted in needless queries bringing back 
data that is not used. All EF generated queries are complicated.
 A mixture of stored procedures and EF context is used within a process 
resulting in incorrect values.


I quite like EF, it's efficient to write queries in if you know what is being 

Re: Entity Framework - the lay of the land

[罗格雷格博士]

It's not SQL functions per se but scalar T-SQL functions. They should be 
inlined like table-valued functions can often be, but they aren't.

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




On Wed, Sep 21, 2016 at 10:22 PM +1000, "Corneliu I. Tusnea" 
> wrote:

I'll jump in with my experience (just last year).
Using EF7 (EF Core 1.0 now?)

I always disliked EF version but I liked the original Linq2Sql which was quite 
lightweight compared to EF.

  1.  Database design and DTO design is very very strictly monitored and 
mapping Table > Entity is very strict with only the exact fields required.
  2.  I find EF perfect for most simple reads of data as long as I don't have 
to join or simple very exact joins. Yes, I know Dapper and PetaPoco but heck, I 
really don't want to maintain strings.
  3.  Views rule. Whenever we need more complicated data we do it in a view. We 
can review, optimize and tweak that as needed.
  4.  SPs rock. Same as above, any work that can be moved in an SP is done in 
an SP (very few scenarios in our case)
  5.  SQL Functions suck. Oh my, they suck and they are hard to fix and 
cumbersome to figure out where perf is bad.
  6.  And most importantly. SQL is long-term-storage NOT the source of truth. 
We use Akka and we (now) consider SQL as eventual storage of data. Everything 
we do is in memory and whenever we have a chance we'll tell SQL about it 
(mostly so after a restart we can start with the data from SQL). You want to 
save some settings? Sure, it's in memory and hey sql, here is an update. Want 
to read a setting? It's in memory no need to ask SQL about it.

I think EF7 (as I said previous versions were garbage), like every other 
technology can be abused.
The problem is that it can be abused way to easily.
Teams use it and abuse it instead of understanding the synergy that needs to 
exist and where the power EF offers should be used.

My 2 cents,
Corneliu.







On Tue, Sep 20, 2016 at 9:06 PM, Tony McGee 
> wrote:
Oh boy, this is a technique I see way underutilised when using EF:
  All objects from EF were transformed into new objects for use in the website

e.g. If I just want a high level list of the product categories a customer has 
purchased, it's far too easily get stuck in a rigid thought pattern due to the 
object model. It says I need a Customer that has an Orders collection each 
having a set of Line Items, dollar values, quantities, special delivery 
instructions, product names, descriptions, packaging dimensions, blah, blah, 
blah NO.
Bringing the whole database across the wire and aggregating in application 
memory is inviting a world of pain.

An EF query projection containing the customer id/name and product category 
name could avoid a huge complicated SELECT * across six different table joins 
that becomes impossible to index.




On 20/09/2016 19:20, David Rhys Jones wrote:

I've been working with EF now for a few years,  here's a list of what went 
wrong / what went right.

Large public Website

Good:
No complex queries in EF, anything more than a couple of tables and a 
stored procedure is called.
All objects from EF were transformed into new objects for use in the website
Bad:
   The context was shared between processes and thusly began to grow after an 
hour or two, causing a slowdown of EF. Regular flushing solved this
  Updates into the database set the FK property but did not attach the object, 
this resulted in data being correct for a moment, but then overwritten with the 
original values when the savechanges was called.


Large Multinational Bank - Bulk Processing
   Good:
   Most processing was done without EF,
  The website used EF to query the same data.
   Bad:
   Framework implemented IEnumerable as each interface, thus   
service.GetClients().Count()  resulted in the entire table being returned. 
Changing the interface to IQueryable allowed the DB to do a count(*)

Large Multinational,  low use public website.
   Good:
  EF context is queried and disposed of as soon as possible, leaving the 
website responsive
   Bad:
 Bad design of the database has resulted in needless queries bringing back 
data that is not used. All EF generated queries are complicated.
 A mixture of stored procedures and EF context is used within a process 
resulting in incorrect values.


I quite like EF, it's efficient to write queries in if you know what is being 
generated at the database level. I always output the SQL query to the debug 
window so I know what is being passed to the DB.
But if the query is not self-contained and requires a lot of tables, then a 
specific stored procedure should be used.  However, do not update with a stored 
procedure if you are using Entity to read back the 

Re: Entity Framework - the lay of the land

[David Rhys Jones]

>> SQL Functions suck. Oh my, they suck and they are hard to fix and
cumbersome to figure out where perf is bad.

I agree, don't use SQL functions in where clauses, joins or aggregates.
It's ok to use if you have a small dataset but otherwise  steer clear.

Davy


*Si hoc legere scis nimium eruditionis habes*.


On Wed, Sep 21, 2016 at 2:22 PM, Corneliu I. Tusnea 
wrote:

> I'll jump in with my experience (just last year).
> Using EF7 (EF Core 1.0 now?)
>
> I always disliked EF version but I liked the original Linq2Sql which was
> quite lightweight compared to EF.
>
>1. Database design and DTO design is very very strictly monitored and
>mapping Table > Entity is very strict with only the exact fields required.
>2. I find EF perfect for most simple reads of data as long as I don't
>have to join or simple very exact joins. Yes, I know Dapper and PetaPoco
>but heck, I really don't want to maintain strings.
>3. Views rule. Whenever we need more complicated data we do it in a
>view. We can review, optimize and tweak that as needed.
>4. SPs rock. Same as above, any work that can be moved in an SP is
>done in an SP (very few scenarios in our case)
>5. SQL Functions suck. Oh my, they suck and they are hard to fix and
>cumbersome to figure out where perf is bad.
>6. And most importantly. SQL is long-term-storage NOT the source of
>truth. We use Akka and we (now) consider SQL as eventual storage of data.
>Everything we do is in memory and whenever we have a chance we'll tell SQL
>about it (mostly so after a restart we can start with the data from SQL).
>You want to save some settings? Sure, it's in memory and hey sql, here is
>an update. Want to read a setting? It's in memory no need to ask SQL about
>it.
>
> I think EF7 (as I said previous versions were garbage), like every other
> technology can be abused.
> The problem is that it can be abused way to easily.
> Teams use it and abuse it instead of understanding the synergy that needs
> to exist and where the power EF offers should be used.
>
> My 2 cents,
> Corneliu.
>
>
>
>
>
>
>
> On Tue, Sep 20, 2016 at 9:06 PM, Tony McGee  wrote:
>
>> Oh boy, this is a technique I see way underutilised when using EF:
>>
>>
>> *All objects from EF were transformed into new objects for use in the
>> website *e.g. If I just want a high level list of the product categories
>> a customer has purchased, it's far too easily get stuck in a rigid thought
>> pattern due to the object model. It says I need a Customer that has an
>> Orders collection each having a set of Line Items, dollar values,
>> quantities, special delivery instructions, product names, descriptions,
>> packaging dimensions, blah, blah, blah NO.
>> Bringing the whole database across the wire and aggregating in
>> application memory is inviting a world of pain.
>>
>> An EF query projection containing the customer id/name and product
>> category name could avoid a huge complicated SELECT * across six different
>> table joins that becomes impossible to index.
>>
>>
>>
>>
>> On 20/09/2016 19:20, David Rhys Jones wrote:
>>
>>
>> I've been working with EF now for a few years,  here's a list of what
>> went wrong / what went right.
>>
>> *Large public Website*
>>
>> *Good:*
>> No complex queries in EF, anything more than a couple of tables and a
>> stored procedure is called.
>> All objects from EF were transformed into new objects for use in the
>> website
>> *Bad:*
>>The context was shared between processes and thusly began to grow
>> after an hour or two, causing a slowdown of EF. Regular flushing solved this
>>   Updates into the database set the FK property but did not attach the
>> object, this resulted in data being correct for a moment, but then
>> overwritten with the original values when the savechanges was called.
>>
>>
>> *Large Multinational Bank - Bulk Processing*
>>*Good:*
>>Most processing was done without EF,
>>   The website used EF to query the same data.
>>*Bad:*
>>Framework implemented IEnumerable as each interface, thus
>> service.GetClients().Count()  resulted in the entire table being returned.
>> Changing the interface to IQueryable allowed the DB to do a count(*)
>>
>> *Large Multinational,  low use public website. *
>>*Good:*
>>   EF context is queried and disposed of as soon as possible, leaving
>> the website responsive
>>*Bad:*
>>  Bad design of the database has resulted in needless queries bringing
>> back data that is not used. All EF generated queries are complicated.
>>  A mixture of stored procedures and EF context is used within a
>> process resulting in incorrect values.
>>
>>
>> I quite like EF, it's efficient to write queries in if you know what is
>> being generated at the database level. I always output the SQL query to the
>> debug window so I know what is being passed to the DB.
>> But if the query is 

Re: Entity Framework - the lay of the land

[Corneliu I. Tusnea]

I'll jump in with my experience (just last year).
Using EF7 (EF Core 1.0 now?)

I always disliked EF version but I liked the original Linq2Sql which was
quite lightweight compared to EF.

   1. Database design and DTO design is very very strictly monitored and
   mapping Table > Entity is very strict with only the exact fields required.
   2. I find EF perfect for most simple reads of data as long as I don't
   have to join or simple very exact joins. Yes, I know Dapper and PetaPoco
   but heck, I really don't want to maintain strings.
   3. Views rule. Whenever we need more complicated data we do it in a
   view. We can review, optimize and tweak that as needed.
   4. SPs rock. Same as above, any work that can be moved in an SP is done
   in an SP (very few scenarios in our case)
   5. SQL Functions suck. Oh my, they suck and they are hard to fix and
   cumbersome to figure out where perf is bad.
   6. And most importantly. SQL is long-term-storage NOT the source of
   truth. We use Akka and we (now) consider SQL as eventual storage of data.
   Everything we do is in memory and whenever we have a chance we'll tell SQL
   about it (mostly so after a restart we can start with the data from SQL).
   You want to save some settings? Sure, it's in memory and hey sql, here is
   an update. Want to read a setting? It's in memory no need to ask SQL about
   it.

I think EF7 (as I said previous versions were garbage), like every other
technology can be abused.
The problem is that it can be abused way to easily.
Teams use it and abuse it instead of understanding the synergy that needs
to exist and where the power EF offers should be used.

My 2 cents,
Corneliu.







On Tue, Sep 20, 2016 at 9:06 PM, Tony McGee  wrote:

> Oh boy, this is a technique I see way underutilised when using EF:
>
>
> *All objects from EF were transformed into new objects for use in the
> website *e.g. If I just want a high level list of the product categories
> a customer has purchased, it's far too easily get stuck in a rigid thought
> pattern due to the object model. It says I need a Customer that has an
> Orders collection each having a set of Line Items, dollar values,
> quantities, special delivery instructions, product names, descriptions,
> packaging dimensions, blah, blah, blah NO.
> Bringing the whole database across the wire and aggregating in application
> memory is inviting a world of pain.
>
> An EF query projection containing the customer id/name and product
> category name could avoid a huge complicated SELECT * across six different
> table joins that becomes impossible to index.
>
>
>
>
> On 20/09/2016 19:20, David Rhys Jones wrote:
>
>
> I've been working with EF now for a few years,  here's a list of what went
> wrong / what went right.
>
> *Large public Website*
>
> *Good:*
> No complex queries in EF, anything more than a couple of tables and a
> stored procedure is called.
> All objects from EF were transformed into new objects for use in the
> website
> *Bad:*
>The context was shared between processes and thusly began to grow after
> an hour or two, causing a slowdown of EF. Regular flushing solved this
>   Updates into the database set the FK property but did not attach the
> object, this resulted in data being correct for a moment, but then
> overwritten with the original values when the savechanges was called.
>
>
> *Large Multinational Bank - Bulk Processing*
>*Good:*
>Most processing was done without EF,
>   The website used EF to query the same data.
>*Bad:*
>Framework implemented IEnumerable as each interface, thus
> service.GetClients().Count()  resulted in the entire table being returned.
> Changing the interface to IQueryable allowed the DB to do a count(*)
>
> *Large Multinational,  low use public website. *
>*Good:*
>   EF context is queried and disposed of as soon as possible, leaving
> the website responsive
>*Bad:*
>  Bad design of the database has resulted in needless queries bringing
> back data that is not used. All EF generated queries are complicated.
>  A mixture of stored procedures and EF context is used within a
> process resulting in incorrect values.
>
>
> I quite like EF, it's efficient to write queries in if you know what is
> being generated at the database level. I always output the SQL query to the
> debug window so I know what is being passed to the DB.
> But if the query is not self-contained and requires a lot of tables, then
> a specific stored procedure should be used.  However, do not update with a
> stored procedure if you are using Entity to read back the values. Do POCO
> updates and read the linked objects and attach them correctly.
>
> Davy.
>
>
>
> *Si hoc legere scis nimium eruditionis habes*.
>
>
> On Tue, Sep 20, 2016 at 10:03 AM, David Connors  wrote:
>
>> On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士)  wrote:
>>
>>> I often get coy when I hear 

Re: Entity Framework - the lay of the land

[David Rhys Jones]

I agree that it's a call that you don't need if you are sure that the
object that you have now has not been updated by someone else.

However even if I was updating via an SQL Statement (SP or inline) then I
would do a select to get the updated line back from the database,
especially if it wasn't an update but rather an insert.
The problem is always how stale your data is, by forcing the update before
the insert you are sure that you have all the latest information before the
update.

Davy



*Si hoc legere scis nimium eruditionis habes*.


On Tue, Sep 20, 2016 at 12:27 PM, Greg Low (罗格雷格博士) <g...@greglow.com>
wrote:

> But if you know the ID of something and you want to update it, why do a
> round trip to read it first, then to do another round trip to update it
> like you could have in the first place?
>
>
>
> 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 *David Rhys Jones
> *Sent:* Tuesday, 20 September 2016 8:03 PM
>
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Entity Framework - the lay of the land
>
>
>
>
>
> That's still the best way to update something
>
>
>
> Get the object first, then update that reference, instead of trying to
> attach a new object with the same Id.
>
>
>
> There is a performance hit, but you are updating it's not needed to be
> quick. If your requirement is speed when updating, then you shouldn't be
> using EF.
>
>
>
> Davy
>
>
>
>
> *Si hoc legere scis nimium eruditionis habes*.
>
>
>
>
>
> On Tue, Sep 20, 2016 at 11:53 AM, Greg Low (罗格雷格博士) <g...@greglow.com>
> wrote:
>
> Have they fixed the update situation yet? I remember that you had to
> select something before you could update it. (At least previously)
>
>
>
> 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 *David Rhys Jones
> *Sent:* Tuesday, 20 September 2016 7:20 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Entity Framework - the lay of the land
>
>
>
>
>
> I've been working with EF now for a few years,  here's a list of what went
> wrong / what went right.
>
>
>
> *Large public Website*
>
>
>
> *Good:*
>
> No complex queries in EF, anything more than a couple of tables and a
> stored procedure is called.
>
> All objects from EF were transformed into new objects for use in the
> website
>
> *Bad:*
>
>The context was shared between processes and thusly began to grow after
> an hour or two, causing a slowdown of EF. Regular flushing solved this
>
>   Updates into the database set the FK property but did not attach the
> object, this resulted in data being correct for a moment, but then
> overwritten with the original values when the savechanges was called.
>
>
>
>
>
> *Large Multinational Bank - Bulk Processing*
>
>*Good:*
>
>Most processing was done without EF,
>
>   The website used EF to query the same data.
>
>*Bad:*
>
>Framework implemented IEnumerable as each interface, thus
> service.GetClients().Count()  resulted in the entire table being returned.
> Changing the interface to IQueryable allowed the DB to do a count(*)
>
>
>
> *Large Multinational,  low use public website. *
>
>*Good:*
>
>   EF context is queried and disposed of as soon as possible, leaving
> the website responsive
>
>*Bad:*
>
>  Bad design of the database has resulted in needless queries bringing
> back data that is not used. All EF generated queries are complicated.
>
>  A mixture of stored procedures and EF context is used within a
> process resulting in incorrect values.
>
>
>
>
>
> I quite like EF, it's efficient to write queries in if you know what is
> being generated at the database level. I always output the SQL query to the
> debug window so I know what is being passed to the DB.
>
> But if the query is not self-contained and requires a lot of tables, then
> a specific stored procedure should be used.  However, do not update with a
> stored procedure if you are using Entity to read back the values. Do POCO
> updates and read

Re: Entity Framework - the lay of the land

[Tony McGee]

Oh boy, this is a technique I see way underutilised when using EF:
/All objects from EF were transformed into new objects for use in the 
website


/e.g. If I just want a high level list of the product categories a 
customer has purchased, it's far too easily get stuck in a rigid thought 
pattern due to the object model. It says I need a Customer that has an 
Orders collection each having a set of Line Items, dollar values, 
quantities, special delivery instructions, product names, descriptions, 
packaging dimensions, blah, blah, blah NO.
Bringing the whole database across the wire and aggregating in 
application memory is inviting a world of pain.


An EF query projection containing the customer id/name and product 
category name could avoid a huge complicated SELECT * across six 
different table joins that becomes impossible to index.




On 20/09/2016 19:20, David Rhys Jones wrote:


I've been working with EF now for a few years,  here's a list of what 
went wrong / what went right.


*Large public Website*
/
/
/Good:/
No complex queries in EF, anything more than a couple of tables 
and a stored procedure is called.
All objects from EF were transformed into new objects for use in 
the website

/Bad:/
   The context was shared between processes and thusly began to grow 
after an hour or two, causing a slowdown of EF. Regular flushing 
solved this
  Updates into the database set the FK property but did not attach the 
object, this resulted in data being correct for a moment, but then 
overwritten with the original values when the savechanges was called.



*Large Multinational Bank - Bulk Processing*
/Good:/
   Most processing was done without EF,
  The website used EF to query the same data.
/Bad:/
   Framework implemented IEnumerable as each interface, thus   
service.GetClients().Count()  resulted in the entire table being 
returned. Changing the interface to IQueryable allowed the DB to do a 
count(*)


*Large Multinational,  low use public website. *
/Good:/
  EF context is queried and disposed of as soon as possible, 
leaving the website responsive

/Bad:/
 Bad design of the database has resulted in needless queries 
bringing back data that is not used. All EF generated queries are 
complicated.
 A mixture of stored procedures and EF context is used within a 
process resulting in incorrect values.



I quite like EF, it's efficient to write queries in if you know what 
is being generated at the database level. I always output the SQL 
query to the debug window so I know what is being passed to the DB.
But if the query is not self-contained and requires a lot of tables, 
then a specific stored procedure should be used. However, do not 
update with a stored procedure if you are using Entity to read back 
the values. Do POCO updates and read the linked objects and attach 
them correctly.


Davy.


/
/
/Si hoc legere scis nimium eruditionis habes/.


On Tue, Sep 20, 2016 at 10:03 AM, David Connors > wrote:


On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士) > wrote:

I often get coy when I hear comparisons with Stack Overflow,
Twitter, Facebook, Blog Engines, etc. though.

Most of those platforms are happy to just throw away
transactions when the going gets heavy.

Also, most of their workloads are read-only and so highly
cacheable at every layer of whatever architecture you choose.

Once you throw consistency and transaction isolation under the bus
shit gets pretty easy pretty quick.

David.

-- 
David Connors

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

RE: Entity Framework - the lay of the land

[罗格雷格博士]

But if you know the ID of something and you want to update it, why do a round 
trip to read it first, then to do another round trip to update it like you 
could have in the first place?

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 David Rhys Jones
Sent: Tuesday, 20 September 2016 8:03 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land


That's still the best way to update something

Get the object first, then update that reference, instead of trying to attach a 
new object with the same Id.

There is a performance hit, but you are updating it's not needed to be quick. 
If your requirement is speed when updating, then you shouldn't be using EF.

Davy


Si hoc legere scis nimium eruditionis habes.


On Tue, Sep 20, 2016 at 11:53 AM, Greg Low (罗格雷格博士) 
<g...@greglow.com<mailto:g...@greglow.com>> wrote:
Have they fixed the update situation yet? I remember that you had to select 
something before you could update it. (At least previously)

Regards,

Greg

Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410<tel:%2B61%20419201410> mobile│ 
+61 3 8676 4913<tel:%2B61%203%208676%204913> 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> 
[mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On 
Behalf Of David Rhys Jones
Sent: Tuesday, 20 September 2016 7:20 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Entity Framework - the lay of the land


I've been working with EF now for a few years,  here's a list of what went 
wrong / what went right.

Large public Website

Good:
No complex queries in EF, anything more than a couple of tables and a 
stored procedure is called.
All objects from EF were transformed into new objects for use in the website
Bad:
   The context was shared between processes and thusly began to grow after an 
hour or two, causing a slowdown of EF. Regular flushing solved this
  Updates into the database set the FK property but did not attach the object, 
this resulted in data being correct for a moment, but then overwritten with the 
original values when the savechanges was called.


Large Multinational Bank - Bulk Processing
   Good:
   Most processing was done without EF,
  The website used EF to query the same data.
   Bad:
   Framework implemented IEnumerable as each interface, thus   
service.GetClients().Count()  resulted in the entire table being returned. 
Changing the interface to IQueryable allowed the DB to do a count(*)

Large Multinational,  low use public website.
   Good:
  EF context is queried and disposed of as soon as possible, leaving the 
website responsive
   Bad:
 Bad design of the database has resulted in needless queries bringing back 
data that is not used. All EF generated queries are complicated.
 A mixture of stored procedures and EF context is used within a process 
resulting in incorrect values.


I quite like EF, it's efficient to write queries in if you know what is being 
generated at the database level. I always output the SQL query to the debug 
window so I know what is being passed to the DB.
But if the query is not self-contained and requires a lot of tables, then a 
specific stored procedure should be used.  However, do not update with a stored 
procedure if you are using Entity to read back the values. Do POCO updates and 
read the linked objects and attach them correctly.

Davy.



Si hoc legere scis nimium eruditionis habes.


On Tue, Sep 20, 2016 at 10:03 AM, David Connors 
<da...@connors.com<mailto:da...@connors.com>> wrote:
On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士) 
<g...@greglow.com<mailto:g...@greglow.com>> wrote:
I often get coy when I hear comparisons with Stack Overflow, Twitter, Facebook, 
Blog Engines, etc. though.
Most of those platforms are happy to just throw away transactions when the 
going gets heavy.
Also, most of their workloads are read-only and so highly cacheable at every 
layer of whatever architecture you choose.

Once you throw consistency and transaction isolation under the bus shit gets 
pretty easy pretty quick.

David.

--
David Connors
da...@connors.com<mailto:da...@connors.com> | @davidconnors | LinkedIn | +61 
417 189 363<tel:%2B61%20417%20189%20363>

Re: Entity Framework - the lay of the land

[David Rhys Jones]

That's still the best way to update something

Get the object first, then update that reference, instead of trying to
attach a new object with the same Id.

There is a performance hit, but you are updating it's not needed to be
quick. If your requirement is speed when updating, then you shouldn't be
using EF.

Davy


*Si hoc legere scis nimium eruditionis habes*.


On Tue, Sep 20, 2016 at 11:53 AM, Greg Low (罗格雷格博士) <g...@greglow.com>
wrote:

> Have they fixed the update situation yet? I remember that you had to
> select something before you could update it. (At least previously)
>
>
>
> 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 *David Rhys Jones
> *Sent:* Tuesday, 20 September 2016 7:20 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Entity Framework - the lay of the land
>
>
>
>
>
> I've been working with EF now for a few years,  here's a list of what went
> wrong / what went right.
>
>
>
> *Large public Website*
>
>
>
> *Good:*
>
> No complex queries in EF, anything more than a couple of tables and a
> stored procedure is called.
>
> All objects from EF were transformed into new objects for use in the
> website
>
> *Bad:*
>
>The context was shared between processes and thusly began to grow after
> an hour or two, causing a slowdown of EF. Regular flushing solved this
>
>   Updates into the database set the FK property but did not attach the
> object, this resulted in data being correct for a moment, but then
> overwritten with the original values when the savechanges was called.
>
>
>
>
>
> *Large Multinational Bank - Bulk Processing*
>
>*Good:*
>
>Most processing was done without EF,
>
>   The website used EF to query the same data.
>
>*Bad:*
>
>Framework implemented IEnumerable as each interface, thus
> service.GetClients().Count()  resulted in the entire table being returned.
> Changing the interface to IQueryable allowed the DB to do a count(*)
>
>
>
> *Large Multinational,  low use public website. *
>
>*Good:*
>
>   EF context is queried and disposed of as soon as possible, leaving
> the website responsive
>
>*Bad:*
>
>  Bad design of the database has resulted in needless queries bringing
> back data that is not used. All EF generated queries are complicated.
>
>  A mixture of stored procedures and EF context is used within a
> process resulting in incorrect values.
>
>
>
>
>
> I quite like EF, it's efficient to write queries in if you know what is
> being generated at the database level. I always output the SQL query to the
> debug window so I know what is being passed to the DB.
>
> But if the query is not self-contained and requires a lot of tables, then
> a specific stored procedure should be used.  However, do not update with a
> stored procedure if you are using Entity to read back the values. Do POCO
> updates and read the linked objects and attach them correctly.
>
>
>
> Davy.
>
>
>
>
>
>
> *Si hoc legere scis nimium eruditionis habes*.
>
>
>
>
>
> On Tue, Sep 20, 2016 at 10:03 AM, David Connors <da...@connors.com> wrote:
>
> On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士) <g...@greglow.com> wrote:
>
> I often get coy when I hear comparisons with Stack Overflow, Twitter,
> Facebook, Blog Engines, etc. though.
>
> Most of those platforms are happy to just throw away transactions when the
> going gets heavy.
>
> Also, most of their workloads are read-only and so highly cacheable at
> every layer of whatever architecture you choose.
>
>
>
> Once you throw consistency and transaction isolation under the bus shit
> gets pretty easy pretty quick.
>
>
>
> David.
>
>
>
> --
>
> David Connors
> da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363
>
>
>

RE: Entity Framework - the lay of the land

[罗格雷格博士]

Have they fixed the update situation yet? I remember that you had to select 
something before you could update it. (At least previously)

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 David Rhys Jones
Sent: Tuesday, 20 September 2016 7:20 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land


I've been working with EF now for a few years,  here's a list of what went 
wrong / what went right.

Large public Website

Good:
No complex queries in EF, anything more than a couple of tables and a 
stored procedure is called.
All objects from EF were transformed into new objects for use in the website
Bad:
   The context was shared between processes and thusly began to grow after an 
hour or two, causing a slowdown of EF. Regular flushing solved this
  Updates into the database set the FK property but did not attach the object, 
this resulted in data being correct for a moment, but then overwritten with the 
original values when the savechanges was called.


Large Multinational Bank - Bulk Processing
   Good:
   Most processing was done without EF,
  The website used EF to query the same data.
   Bad:
   Framework implemented IEnumerable as each interface, thus   
service.GetClients().Count()  resulted in the entire table being returned. 
Changing the interface to IQueryable allowed the DB to do a count(*)

Large Multinational,  low use public website.
   Good:
  EF context is queried and disposed of as soon as possible, leaving the 
website responsive
   Bad:
 Bad design of the database has resulted in needless queries bringing back 
data that is not used. All EF generated queries are complicated.
 A mixture of stored procedures and EF context is used within a process 
resulting in incorrect values.


I quite like EF, it's efficient to write queries in if you know what is being 
generated at the database level. I always output the SQL query to the debug 
window so I know what is being passed to the DB.
But if the query is not self-contained and requires a lot of tables, then a 
specific stored procedure should be used.  However, do not update with a stored 
procedure if you are using Entity to read back the values. Do POCO updates and 
read the linked objects and attach them correctly.

Davy.



Si hoc legere scis nimium eruditionis habes.


On Tue, Sep 20, 2016 at 10:03 AM, David Connors 
<da...@connors.com<mailto:da...@connors.com>> wrote:
On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士) 
<g...@greglow.com<mailto:g...@greglow.com>> wrote:
I often get coy when I hear comparisons with Stack Overflow, Twitter, Facebook, 
Blog Engines, etc. though.
Most of those platforms are happy to just throw away transactions when the 
going gets heavy.
Also, most of their workloads are read-only and so highly cacheable at every 
layer of whatever architecture you choose.

Once you throw consistency and transaction isolation under the bus shit gets 
pretty easy pretty quick.

David.

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

Re: Entity Framework - the lay of the land

[David Rhys Jones]

I've been working with EF now for a few years,  here's a list of what went
wrong / what went right.

*Large public Website*

*Good:*
No complex queries in EF, anything more than a couple of tables and a
stored procedure is called.
All objects from EF were transformed into new objects for use in the
website
*Bad:*
   The context was shared between processes and thusly began to grow after
an hour or two, causing a slowdown of EF. Regular flushing solved this
  Updates into the database set the FK property but did not attach the
object, this resulted in data being correct for a moment, but then
overwritten with the original values when the savechanges was called.


*Large Multinational Bank - Bulk Processing*
   *Good:*
   Most processing was done without EF,
  The website used EF to query the same data.
   *Bad:*
   Framework implemented IEnumerable as each interface, thus
service.GetClients().Count()  resulted in the entire table being returned.
Changing the interface to IQueryable allowed the DB to do a count(*)

*Large Multinational,  low use public website. *
   *Good:*
  EF context is queried and disposed of as soon as possible, leaving
the website responsive
   *Bad:*
 Bad design of the database has resulted in needless queries bringing
back data that is not used. All EF generated queries are complicated.
 A mixture of stored procedures and EF context is used within a process
resulting in incorrect values.


I quite like EF, it's efficient to write queries in if you know what is
being generated at the database level. I always output the SQL query to the
debug window so I know what is being passed to the DB.
But if the query is not self-contained and requires a lot of tables, then a
specific stored procedure should be used.  However, do not update with a
stored procedure if you are using Entity to read back the values. Do POCO
updates and read the linked objects and attach them correctly.

Davy.



*Si hoc legere scis nimium eruditionis habes*.


On Tue, Sep 20, 2016 at 10:03 AM, David Connors  wrote:

> On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士)  wrote:
>
>> I often get coy when I hear comparisons with Stack Overflow, Twitter,
>> Facebook, Blog Engines, etc. though.
>>
>> Most of those platforms are happy to just throw away transactions when
>> the going gets heavy.
>>
> Also, most of their workloads are read-only and so highly cacheable at
> every layer of whatever architecture you choose.
>
> Once you throw consistency and transaction isolation under the bus shit
> gets pretty easy pretty quick.
>
> David.
>
> --
> David Connors
> da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363
>

Re: Entity Framework - the lay of the land

[David Connors]

On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士)  wrote:

> I often get coy when I hear comparisons with Stack Overflow, Twitter,
> Facebook, Blog Engines, etc. though.
>
> Most of those platforms are happy to just throw away transactions when the
> going gets heavy.
>
Also, most of their workloads are read-only and so highly cacheable at
every layer of whatever architecture you choose.

Once you throw consistency and transaction isolation under the bus shit
gets pretty easy pretty quick.

David.

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

Re: Entity Framework - the lay of the land

[Scott Barnes]

Well there you go, signs they are continuing to invest... as now it's moved
from an organic form into solid form ... i.e., it was a virus last time I
saw it, now its an actual physical metal object (bullet).

*drops mic*

---
Regards,
Scott Barnes
http://www.riagenic.com

On Tue, Sep 20, 2016 at 2:00 PM, Greg Low (罗格雷格博士) <g...@greglow.com> wrote:

> When I posted on Facebook about it the other day, another Microsoft friend
> noted that he was going to be the product manager for EF, but commented
> that he managed “to dodge that bullet”.
>
>
>
> 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 *Scott Barnes
> *Sent:* Tuesday, 20 September 2016 1:42 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Entity Framework - the lay of the land
>
>
>
> Entity Framework was born out of many attempts to solve the DAL tier to
> enable developers to have to avoid talking to DBA's directly. The amount of
> churn its gone through and the level of pain it rewards doesn't seem imho
> to justify its adoption.
>
>
>
> As for forgotten child. I can't speak to the program management level but
> when I was in the product management side of things we avoided that clump
> of code as much as possible. It was too hard to build a narrative around
> and even when we managed to wrangle the mess into a coherent strategy
> they'd turn and flip the table over with "i have a better idea on how to
> solve this pattern.." and sure as your google search for "CRUD
> EntityFramework" the entire blogosphere would leave you in the corner,
> confused and wondering aimlessly as if to say out loud "I trusted them,
> they...they have cheated me for the last time".
>
> I recently watched a Unity3D dev switch to using web-centric .net dev, and
> he died a miserable painful death on Entity Framework code-first. To quote
> "I went to use the migration strategy it left me a broken man, it just
> doesn't work as its advertised".
>
> Its time to put this and PRISM in the "GitHub" graveyard. Say out loud you
> support it but block any future pull requests.
>
>
>
>
> ---
> Regards,
> Scott Barnes
> http://www.riagenic.com
>
>
>
> On Tue, Sep 20, 2016 at 1:33 PM, Craig van Nieuwkerk <crai...@gmail.com>
> wrote:
>
> To give more info, 99% of the CUD was done via NHibernate. For simple
> select queries like for lookup lists was also done via NHibernate, using
> the built in caching and Redis cache, but more complicated queries were
> straight SQL and PetaPoco.
>
>
>
> Craig
>
>
>
>
>
> On Tue, Sep 20, 2016 at 1:30 PM, Craig van Nieuwkerk <crai...@gmail.com>
> wrote:
>
> Not EF but have used NHibernate in application, in conjunction with
> optimised SQL where required, and easily supported 1000+ users. But it is
> very easy to stuff it up and find you can't support 5 simultaneous users.
>
>
>
> Even StackOverflow before it used Dapper used LinqToSql. Of course, they
> had to optimise and go to Dapper but the LinqToSql version still supported
> heaps of traffic.
>
>
>
> Craig
>
>
>
> On Tue, Sep 20, 2016 at 1:22 PM, David Apelt <d...@signmanager.com.au>
> wrote:
>
> Thanks everyone for their contributions to my original questions.   I am a
> little surprised about how poor people’s real world experience has been
> with the EF and other ORMs.
>
>
>
> A little poll;
>
>
>
> Is anyone successfully using EF in a production environment for a
> non-trivial application?  And if yes, then why has yours worked where
> others have failed.
>
>
>
> Regards
>
> Dave A
>
>
>
>
>
>
>
>
>

RE: Entity Framework - the lay of the land

[罗格雷格博士]

When I posted on Facebook about it the other day, another Microsoft friend 
noted that he was going to be the product manager for EF, but commented that he 
managed “to dodge that bullet”.

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 Scott Barnes
Sent: Tuesday, 20 September 2016 1:42 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

Entity Framework was born out of many attempts to solve the DAL tier to enable 
developers to have to avoid talking to DBA's directly. The amount of churn its 
gone through and the level of pain it rewards doesn't seem imho to justify its 
adoption.

As for forgotten child. I can't speak to the program management level but when 
I was in the product management side of things we avoided that clump of code as 
much as possible. It was too hard to build a narrative around and even when we 
managed to wrangle the mess into a coherent strategy they'd turn and flip the 
table over with "i have a better idea on how to solve this pattern.." and sure 
as your google search for "CRUD EntityFramework" the entire blogosphere would 
leave you in the corner, confused and wondering aimlessly as if to say out loud 
"I trusted them, they...they have cheated me for the last time".

I recently watched a Unity3D dev switch to using web-centric .net dev, and he 
died a miserable painful death on Entity Framework code-first. To quote "I went 
to use the migration strategy it left me a broken man, it just doesn't work as 
its advertised".

Its time to put this and PRISM in the "GitHub" graveyard. Say out loud you 
support it but block any future pull requests.


---
Regards,
Scott Barnes
http://www.riagenic.com

On Tue, Sep 20, 2016 at 1:33 PM, Craig van Nieuwkerk 
<crai...@gmail.com<mailto:crai...@gmail.com>> wrote:
To give more info, 99% of the CUD was done via NHibernate. For simple select 
queries like for lookup lists was also done via NHibernate, using the built in 
caching and Redis cache, but more complicated queries were straight SQL and 
PetaPoco.

Craig


On Tue, Sep 20, 2016 at 1:30 PM, Craig van Nieuwkerk 
<crai...@gmail.com<mailto:crai...@gmail.com>> wrote:
Not EF but have used NHibernate in application, in conjunction with optimised 
SQL where required, and easily supported 1000+ users. But it is very easy to 
stuff it up and find you can't support 5 simultaneous users.

Even StackOverflow before it used Dapper used LinqToSql. Of course, they had to 
optimise and go to Dapper but the LinqToSql version still supported heaps of 
traffic.

Craig

On Tue, Sep 20, 2016 at 1:22 PM, David Apelt 
<d...@signmanager.com.au<mailto:d...@signmanager.com.au>> wrote:
Thanks everyone for their contributions to my original questions.   I am a 
little surprised about how poor people’s real world experience has been with 
the EF and other ORMs.

A little poll;

Is anyone successfully using EF in a production environment for a non-trivial 
application?  And if yes, then why has yours worked where others have failed.

Regards
Dave A

RE: Entity Framework - the lay of the land

[罗格雷格博士]

Hey Craig,

I often get coy when I hear comparisons with Stack Overflow, Twitter, Facebook, 
Blog Engines, etc. though.

Most of those platforms are happy to just throw away transactions when the 
going gets heavy.

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 Craig van Nieuwkerk
Sent: Tuesday, 20 September 2016 1:33 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

To give more info, 99% of the CUD was done via NHibernate. For simple select 
queries like for lookup lists was also done via NHibernate, using the built in 
caching and Redis cache, but more complicated queries were straight SQL and 
PetaPoco.

Craig

On Tue, Sep 20, 2016 at 1:30 PM, Craig van Nieuwkerk 
<crai...@gmail.com<mailto:crai...@gmail.com>> wrote:
Not EF but have used NHibernate in application, in conjunction with optimised 
SQL where required, and easily supported 1000+ users. But it is very easy to 
stuff it up and find you can't support 5 simultaneous users.

Even StackOverflow before it used Dapper used LinqToSql. Of course, they had to 
optimise and go to Dapper but the LinqToSql version still supported heaps of 
traffic.

Craig

On Tue, Sep 20, 2016 at 1:22 PM, David Apelt 
<d...@signmanager.com.au<mailto:d...@signmanager.com.au>> wrote:
Thanks everyone for their contributions to my original questions.   I am a 
little surprised about how poor people’s real world experience has been with 
the EF and other ORMs.

A little poll;

Is anyone successfully using EF in a production environment for a non-trivial 
application?  And if yes, then why has yours worked where others have failed.

Regards
Dave A

Re: Entity Framework - the lay of the land

[Craig van Nieuwkerk]

To give more info, 99% of the CUD was done via NHibernate. For simple
select queries like for lookup lists was also done via NHibernate, using
the built in caching and Redis cache, but more complicated queries were
straight SQL and PetaPoco.

Craig

On Tue, Sep 20, 2016 at 1:30 PM, Craig van Nieuwkerk 
wrote:

> Not EF but have used NHibernate in application, in conjunction with
> optimised SQL where required, and easily supported 1000+ users. But it is
> very easy to stuff it up and find you can't support 5 simultaneous users.
>
> Even StackOverflow before it used Dapper used LinqToSql. Of course, they
> had to optimise and go to Dapper but the LinqToSql version still supported
> heaps of traffic.
>
> Craig
>
> On Tue, Sep 20, 2016 at 1:22 PM, David Apelt 
> wrote:
>
>> Thanks everyone for their contributions to my original questions.   I am
>> a little surprised about how poor people’s real world experience has been
>> with the EF and other ORMs.
>>
>>
>>
>> A little poll;
>>
>>
>>
>> Is anyone successfully using EF in a production environment for a
>> non-trivial application?  And if yes, then why has yours worked where
>> others have failed.
>>
>>
>>
>> Regards
>>
>> Dave A
>>
>>
>>
>>
>>
>

Re: Entity Framework - the lay of the land

[Craig van Nieuwkerk]

Not EF but have used NHibernate in application, in conjunction with
optimised SQL where required, and easily supported 1000+ users. But it is
very easy to stuff it up and find you can't support 5 simultaneous users.

Even StackOverflow before it used Dapper used LinqToSql. Of course, they
had to optimise and go to Dapper but the LinqToSql version still supported
heaps of traffic.

Craig

On Tue, Sep 20, 2016 at 1:22 PM, David Apelt 
wrote:

> Thanks everyone for their contributions to my original questions.   I am a
> little surprised about how poor people’s real world experience has been
> with the EF and other ORMs.
>
>
>
> A little poll;
>
>
>
> Is anyone successfully using EF in a production environment for a
> non-trivial application?  And if yes, then why has yours worked where
> others have failed.
>
>
>
> Regards
>
> Dave A
>
>
>
>
>

RE: Entity Framework - the lay of the land

[David Apelt]

Thanks everyone for their contributions to my original questions.   I am a 
little surprised about how poor people’s real world experience has been with 
the EF and other ORMs.

A little poll;

Is anyone successfully using EF in a production environment for a non-trivial 
application?  And if yes, then why has yours worked where others have failed.

Regards
Dave A


From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low (??)
Sent: Monday, September 19, 2016 5:47 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: RE: Entity Framework - the lay of the land

Agreed Ken. Actually I had another odd one about a year ago with a large bank 
(which bank?).

If I did a transaction search with:

From Date: start of the month
To Date: end of the month

a particular transaction on the last day of the month appeared. But if I 
selected:

From Date: end of the month
To Date: also end of the month

In the same screen, one of the transactions on that end-of-month date 
disappeared.

Turns out that one outcome was based on transaction date, the other was based 
on posting date. But pretty bizarre when you’re only dealing with dates on the 
same screen.

I can imagine what leads to this sort of thing though.

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> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ken Schaefer
Sent: Monday, 19 September 2016 5:15 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Entity Framework - the lay of the land

A large bank (like one of the Big4 in Aus) has a staggering number of 
applications. Even running what you’d think is the simplest product results in 
multiple applications being involved, whether opening an account through to 
day-to-day transacting, especially given the multiple channels that might be 
available.

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low (??)
Sent: Monday, 19 September 2016 3:23 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Entity Framework - the lay of the land

People always use banks as the canonical example, but I had one at a local bank 
where I went to an ATM and did a transfer “From Account” -> “To Account” where 
both accounts were with the same bank.

Came out of the “from”, and never went into the “to”.

After what seemed like hours on the phone, they told me that “the person who 
had typed in the account number had got it wrong”.

I said “person???” “type”

That’s when they explained to me that their savings system wasn’t really 
connected to their credit card system, and on that afternoon the integration 
link had broken down, so they were printing out the transactions on one and 
typing them into the other. There really was a little person in the ATM.

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> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Stephen Price
Sent: Monday, 19 September 2016 1:50 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Entity Framework - the lay of the land


While on the topic of databases...



I made a flight booking via Altitude points system yesterday and if failed. 
Gave me a number to call during business hours.



Turns out just the return flight was made but nothing charged. That's not very 
atomic hey? []



Hehe love that dialup db connection idea...


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
<ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>> on behalf 
of Greg Low (罗格雷格博士) <g...@greglow.com<mailto:g...@greglow.com>>
Sent: Monday, 19 September 2016 11:06:05 AM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land

I remember many years ago, connecting the devs to the DB via a dial-up 64kB 
modem. Worked wonders for the code that came back. Suddenly they noticed every 
call.

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> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Connors
Sent: Monday

RE: Entity Framework - the lay of the land

[罗格雷格博士]

Agreed Ken. Actually I had another odd one about a year ago with a large bank 
(which bank?).

If I did a transaction search with:

From Date: start of the month
To Date: end of the month

a particular transaction on the last day of the month appeared. But if I 
selected:

From Date: end of the month
To Date: also end of the month

In the same screen, one of the transactions on that end-of-month date 
disappeared.

Turns out that one outcome was based on transaction date, the other was based 
on posting date. But pretty bizarre when you’re only dealing with dates on the 
same screen.

I can imagine what leads to this sort of thing though.

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 Ken Schaefer
Sent: Monday, 19 September 2016 5:15 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: RE: Entity Framework - the lay of the land

A large bank (like one of the Big4 in Aus) has a staggering number of 
applications. Even running what you’d think is the simplest product results in 
multiple applications being involved, whether opening an account through to 
day-to-day transacting, especially given the multiple channels that might be 
available.

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Low (??)
Sent: Monday, 19 September 2016 3:23 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Entity Framework - the lay of the land

People always use banks as the canonical example, but I had one at a local bank 
where I went to an ATM and did a transfer “From Account” -> “To Account” where 
both accounts were with the same bank.

Came out of the “from”, and never went into the “to”.

After what seemed like hours on the phone, they told me that “the person who 
had typed in the account number had got it wrong”.

I said “person???” “type”

That’s when they explained to me that their savings system wasn’t really 
connected to their credit card system, and on that afternoon the integration 
link had broken down, so they were printing out the transactions on one and 
typing them into the other. There really was a little person in the ATM.

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> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Stephen Price
Sent: Monday, 19 September 2016 1:50 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Entity Framework - the lay of the land


While on the topic of databases...



I made a flight booking via Altitude points system yesterday and if failed. 
Gave me a number to call during business hours.



Turns out just the return flight was made but nothing charged. That's not very 
atomic hey? []



Hehe love that dialup db connection idea...


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
<ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>> on behalf 
of Greg Low (罗格雷格博士) <g...@greglow.com<mailto:g...@greglow.com>>
Sent: Monday, 19 September 2016 11:06:05 AM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land

I remember many years ago, connecting the devs to the DB via a dial-up 64kB 
modem. Worked wonders for the code that came back. Suddenly they noticed every 
call.

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> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Connors
Sent: Monday, 19 September 2016 12:34 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Entity Framework - the lay of the land

On Mon, 19 Sep 2016 at 10:38 Greg Keogh 
<gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote:
I had an argument internally that caching was good, with the alternate side 
saying that “cache invalidation” was hard so they never use it.
I think it is "hard" but don't write it off completely. Search for "second 
level cache" and you'll see it's not that trivial to use properly. Some ORMs 
have it as an optional feature. You've got to consider what to cache, eviction 
or expiry policy, concurrency, capacity

RE: Entity Framework - the lay of the land

[Ken Schaefer]

A large bank (like one of the Big4 in Aus) has a staggering number of 
applications. Even running what you’d think is the simplest product results in 
multiple applications being involved, whether opening an account through to 
day-to-day transacting, especially given the multiple channels that might be 
available.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low (??)
Sent: Monday, 19 September 2016 3:23 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: RE: Entity Framework - the lay of the land

People always use banks as the canonical example, but I had one at a local bank 
where I went to an ATM and did a transfer “From Account” -> “To Account” where 
both accounts were with the same bank.

Came out of the “from”, and never went into the “to”.

After what seemed like hours on the phone, they told me that “the person who 
had typed in the account number had got it wrong”.

I said “person???” “type”

That’s when they explained to me that their savings system wasn’t really 
connected to their credit card system, and on that afternoon the integration 
link had broken down, so they were printing out the transactions on one and 
typing them into the other. There really was a little person in the ATM.

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> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Stephen Price
Sent: Monday, 19 September 2016 1:50 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Entity Framework - the lay of the land


While on the topic of databases...



I made a flight booking via Altitude points system yesterday and if failed. 
Gave me a number to call during business hours.



Turns out just the return flight was made but nothing charged. That's not very 
atomic hey? []



Hehe love that dialup db connection idea...


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
<ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>> on behalf 
of Greg Low (罗格雷格博士) <g...@greglow.com<mailto:g...@greglow.com>>
Sent: Monday, 19 September 2016 11:06:05 AM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land

I remember many years ago, connecting the devs to the DB via a dial-up 64kB 
modem. Worked wonders for the code that came back. Suddenly they noticed every 
call.

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> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Connors
Sent: Monday, 19 September 2016 12:34 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Entity Framework - the lay of the land

On Mon, 19 Sep 2016 at 10:38 Greg Keogh 
<gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote:
I had an argument internally that caching was good, with the alternate side 
saying that “cache invalidation” was hard so they never use it.
I think it is "hard" but don't write it off completely. Search for "second 
level cache" and you'll see it's not that trivial to use properly. Some ORMs 
have it as an optional feature. You've got to consider what to cache, eviction 
or expiry policy, concurrency, capacity, etc. I implemented simple caching in a 
server app a long time ago, then about year later I put performance counters 
into the code and discovered that in live use the cache was usually going empty 
before it was accessed, so it was mostly ineffective. Luckily I could tweak it 
into working. So caching is great, but be careful -- GK

I'd argue caching is a good idea so long as it is not a substitute for good 
performance optimisation as you go.

As a general discipline we roll with a rule I call "10x representative data 
load" which means we take whatever we think the final system is going to run 
with for a data set, load each dev with 10x of that on their workstations, and 
make them live that dream.

The reality is that a bit of planning for optimal indexes as well as casting an 
eye over the execution plan after you write each proc isn't a lot of dev 
overhead. At least you know when what you have built rolls out it performs as 
well as it can given other constraints.

David.




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

RE: Entity Framework - the lay of the land

[罗格雷格博士]

People always use banks as the canonical example, but I had one at a local bank 
where I went to an ATM and did a transfer “From Account” -> “To Account” where 
both accounts were with the same bank.

Came out of the “from”, and never went into the “to”.

After what seemed like hours on the phone, they told me that “the person who 
had typed in the account number had got it wrong”.

I said “person???” “type”

That’s when they explained to me that their savings system wasn’t really 
connected to their credit card system, and on that afternoon the integration 
link had broken down, so they were printing out the transactions on one and 
typing them into the other. There really was a little person in the ATM.

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 Stephen Price
Sent: Monday, 19 September 2016 1:50 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land


While on the topic of databases...



I made a flight booking via Altitude points system yesterday and if failed. 
Gave me a number to call during business hours.



Turns out just the return flight was made but nothing charged. That's not very 
atomic hey? []



Hehe love that dialup db connection idea...


From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
<ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>> on behalf 
of Greg Low (罗格雷格博士) <g...@greglow.com<mailto:g...@greglow.com>>
Sent: Monday, 19 September 2016 11:06:05 AM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land

I remember many years ago, connecting the devs to the DB via a dial-up 64kB 
modem. Worked wonders for the code that came back. Suddenly they noticed every 
call.

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> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Connors
Sent: Monday, 19 September 2016 12:34 PM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: Re: Entity Framework - the lay of the land

On Mon, 19 Sep 2016 at 10:38 Greg Keogh 
<gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote:
I had an argument internally that caching was good, with the alternate side 
saying that “cache invalidation” was hard so they never use it.
I think it is "hard" but don't write it off completely. Search for "second 
level cache" and you'll see it's not that trivial to use properly. Some ORMs 
have it as an optional feature. You've got to consider what to cache, eviction 
or expiry policy, concurrency, capacity, etc. I implemented simple caching in a 
server app a long time ago, then about year later I put performance counters 
into the code and discovered that in live use the cache was usually going empty 
before it was accessed, so it was mostly ineffective. Luckily I could tweak it 
into working. So caching is great, but be careful -- GK

I'd argue caching is a good idea so long as it is not a substitute for good 
performance optimisation as you go.

As a general discipline we roll with a rule I call "10x representative data 
load" which means we take whatever we think the final system is going to run 
with for a data set, load each dev with 10x of that on their workstations, and 
make them live that dream.

The reality is that a bit of planning for optimal indexes as well as casting an 
eye over the execution plan after you write each proc isn't a lot of dev 
overhead. At least you know when what you have built rolls out it performs as 
well as it can given other constraints.

David.




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

RE: Entity Framework - the lay of the land

[罗格雷格博士]

I remember many years ago, connecting the devs to the DB via a dial-up 64kB 
modem. Worked wonders for the code that came back. Suddenly they noticed every 
call.

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 David Connors
Sent: Monday, 19 September 2016 12:34 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

On Mon, 19 Sep 2016 at 10:38 Greg Keogh 
<gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote:
I had an argument internally that caching was good, with the alternate side 
saying that “cache invalidation” was hard so they never use it.
I think it is "hard" but don't write it off completely. Search for "second 
level cache" and you'll see it's not that trivial to use properly. Some ORMs 
have it as an optional feature. You've got to consider what to cache, eviction 
or expiry policy, concurrency, capacity, etc. I implemented simple caching in a 
server app a long time ago, then about year later I put performance counters 
into the code and discovered that in live use the cache was usually going empty 
before it was accessed, so it was mostly ineffective. Luckily I could tweak it 
into working. So caching is great, but be careful -- GK

I'd argue caching is a good idea so long as it is not a substitute for good 
performance optimisation as you go.

As a general discipline we roll with a rule I call "10x representative data 
load" which means we take whatever we think the final system is going to run 
with for a data set, load each dev with 10x of that on their workstations, and 
make them live that dream.

The reality is that a bit of planning for optimal indexes as well as casting an 
eye over the execution plan after you write each proc isn't a lot of dev 
overhead. At least you know when what you have built rolls out it performs as 
well as it can given other constraints.

David.




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

Re: Entity Framework - the lay of the land

[Craig van Nieuwkerk]

Correct, in a web app for example, you can often do very short lived
caching for the life of a request.

On Mon, Sep 19, 2016 at 11:39 AM, Tony Wright  wrote:

> I do like caching. And you often don't need to cache for very long anyway
> to get significant benefits.
> T.
>
>

Re: Entity Framework - the lay of the land

[Tony Wright]

I do like caching. And you often don't need to cache for very long anyway
to get significant benefits.
T.

On Mon, Sep 19, 2016 at 11:35 AM, Paul Glavich <subscripti...@theglavs.com>
wrote:

> Cache invalidation can be hard in tight race conditions and a few others.
> There are many instances where it can be very easy based on use cases and
> data needs. I have used it to great effect for many years.
>
>
>
> Like you mentioned, do not write off because it can be hard. Kinda like
> designing and implementing solutions J
>
>
>
> Note: I have never used ORM caching functionlity and probably never will.
>
>
>
> -  Glav
>
>
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@
> ozdotnet.com] *On Behalf Of *Greg Keogh
> *Sent:* Monday, 19 September 2016 10:38 AM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Entity Framework - the lay of the land
>
>
>
> I had an argument internally that caching was good, with the alternate
> side saying that “cache invalidation” was hard so they never use it.
>
>
>
> I think it is "hard" but don't write it off completely. Search for "second
> level cache" and you'll see it's not that trivial to use properly. Some
> ORMs have it as an optional feature. You've got to consider what to cache,
> eviction or expiry policy, concurrency, capacity, etc. I implemented simple
> caching in a server app a long time ago, then about year later I put
> performance counters into the code and discovered that in live use the
> cache was usually going empty before it was accessed, so it was mostly
> ineffective. Luckily I could tweak it into working. So caching is great,
> but be careful -- *GK*
>

RE: Entity Framework - the lay of the land

[Paul Glavich]

Cache invalidation can be hard in tight race conditions and a few others. There 
are many instances where it can be very easy based on use cases and data needs. 
I have used it to great effect for many years.

 

Like you mentioned, do not write off because it can be hard. Kinda like 
designing and implementing solutions :)

 

Note: I have never used ORM caching functionlity and probably never will.

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Monday, 19 September 2016 10:38 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

 

I had an argument internally that caching was good, with the alternate side 
saying that “cache invalidation” was hard so they never use it.

 

I think it is "hard" but don't write it off completely. Search for "second 
level cache" and you'll see it's not that trivial to use properly. Some ORMs 
have it as an optional feature. You've got to consider what to cache, eviction 
or expiry policy, concurrency, capacity, etc. I implemented simple caching in a 
server app a long time ago, then about year later I put performance counters 
into the code and discovered that in live use the cache was usually going empty 
before it was accessed, so it was mostly ineffective. Luckily I could tweak it 
into working. So caching is great, but be careful -- GK

Re: Entity Framework - the lay of the land

[Greg Keogh]

>
> I had an argument internally that caching was good, with the alternate
> side saying that “cache invalidation” was hard so they never use it.
>

I think it is "hard" but don't write it off completely. Search for "second
level cache" and you'll see it's not that trivial to use properly. Some
ORMs have it as an optional feature. You've got to consider what to cache,
eviction or expiry policy, concurrency, capacity, etc. I implemented simple
caching in a server app a long time ago, then about year later I put
performance counters into the code and discovered that in live use the
cache was usually going empty before it was accessed, so it was mostly
ineffective. Luckily I could tweak it into working. So caching is great,
but be careful -- *GK*

RE: Entity Framework - the lay of the land

[Paul Glavich]

>> Finally, caching is your friend. I'm called in all the time to help with 
>> concurrency and scale issues. The #1 way to get a DB to scale is to stop 
>> talking to it in the first place.

Boom. I have been advocating that for years. That line is almost exactly the 
one I used in my performance book too.

 

I had an argument internally that caching was good, with the alternate side 
saying that “cache invalidation” was hard so they never use it.

 

Good to know my opinion is officially endorsed by “The good doctor” :)

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Low (??)
Sent: Sunday, 18 September 2016 11:47 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

 

Three other key aspects of this:

 

If your table design matches your object design, at least one of them is a poor 
design (again I'm talking about serious apps). Yet most ORMs start with this 
assumption.

 

If you don't bypass your normal object access paths for high speed operations, 
you'll have serious perf issues. It might seem clean to load up a set of 
entities to filter and paginate them on each call. People who do that keep 
generating work for people like me though.

 

Finally, caching is your friend. I'm called in all the time to help with 
concurrency and scale issues. The #1 way to get a DB to scale is to stop 
talking to it in the first place.

 

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> 

 

_
From: Greg Low (罗格雷格博士) <g...@greglow.com <mailto:g...@greglow.com> >
Sent: Saturday, September 17, 2016 11:11 AM
Subject: RE: Entity Framework - the lay of the land
To: ozDotNet <ozdotnet@ozdotnet.com <mailto:ozdotnet@ozdotnet.com> >





And if you have two days free on 28th/29th of this month,  come 
and spend those days on starting to get your head around query performance:  
<http://www.sqldownunder.com/Training/Courses/3> 
http://www.sqldownunder.com/Training/Courses/3   (And sorry, 
Melbourne only this year. Might get time mid-next year for a Sydney one).

 

Regards,

 

Greg

 

Dr Greg Low

 

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax

SQL Down Under| Web: <http://www.sqldownunder.com/> www.sqldownunder.com | 
<http://greglow.me/> http://greglow.me

 

From: Greg Low (罗格雷格博士)
Sent: Saturday, 17 September 2016 11:04 AM
To: ozDotNet <ozdotnet@ozdotnet.com <mailto:ozdotnet@ozdotnet.com> >
Subject: RE: Entity Framework - the lay of the land

 

Hey Dave and all,

 

“The great” -> hardly but thanks Dave.

 

Look, my issues with many of these ORMs are many. Unfortunately, I spend my 
life on the back end of trying to deal with the messes involved. The following 
are the key issues that I see:

 

Potentially horrid performance

 

I’ve been on the back end of this all the time. There are several reasons. One 
is that the frameworks generate horrid code to start with, the second is that 
they are typically quite resistant to improvement, the third is that they tend 
to encourage processing with far too much data movement.

 

I regularly end up in software houses with major issues that they don’t know 
how to solve. As an example, I was at a start-up software house recently. They 
had had a team of 10 developers building an application for the last four 
years. The business owner said that if it would support 1000 concurrent users, 
they would have a viable business. 5000 would make a good business. 500 they 
might survive. They had their first serious performance test two weeks before 
they had to show the investors. It fell over with 9 concurrent users. The 
management (and in this case the devs too) were panic-stricken.

 

Another recent example was a software house that had to deliver an app to a 
government department. They were already 4 weeks overdue and couldn’t get it 
out of UAT. They wanted a silver bullet. That’s not the point to then be 
discussing their architectural decisions yet they were the issue.

 

I was in a large financial in Sydney a while back. They were in the middle of 
removing the ORM that they’d chosen out of their app because try as they might, 
they couldn’t get anywhere near the required performance numbers. Why had they 
called me in? Because before they wrote off 8 months’ work for 240 developers, 
the management wanted another opinion.

 

Just yesterday I was working on a background processing job that processes a 
certain type of share trades in a UK-based financial service organisation. On a 
system with 48 processors, and 1.2 TB of memory, and 7 x 1 million UK pound 
20TB flash drive arrays, it ran for 48 minutes. During that time, it issued 550 
million SQL batches to be processed and al

Re: Entity Framework - the lay of the land

[罗格雷格博士]

Simple examples are anything many to many. If I have passengers on flights, I 
might have a Flights table, a Passengers table and perhaps some sort of 
FlightManifests table (who's on which flights).

But I sure wouldn't want those three as objects. I'd probably want a Passenger 
object with a Flights collection, and a Flight object with a Passengers 
collection.

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




On Sun, Sep 18, 2016 at 2:28 PM +1000, "Greg Keogh" 
> wrote:

GL

If your table design matches your object design, at least one of them is a poor 
design (again I'm talking about serious apps).

Then there's no hope. Game over man! It was easier for Jeff Goldblum to plug 
his laptop into an alien mothership that it is for coders and DBAs to exchange 
data effectively. Perhaps the relational database is a niche evolutionary 
branch that just gained too much popularity in the last 30 years and is now 
overused or incorrectly used and we all take if for granted. Robust RDBs come 
in all sizes and prices, many free, so they're just everywhere and you use them 
without thinking. Codd might regret his legacy!

You must have experienced many situations where some business data doesn't feel 
right in an RDB and you finish up with self-joins and tricks to mimic 
hierarchies, inheritance or represent temporal data. If other people have 
stumbled into this situation and have opted for an effective non-RDB solution 
then I'm keen to hear what happened.

In light of this whole discussion though, in future I'm going to be more 
careful about bridging the code-to-DB gap. Rather than just lazily spiting out 
wads of ORM generated code and throwing it at the DB, I'm going to consider how 
to use views and procs more effectively to do what they do best.

GK

Re: Entity Framework - the lay of the land

[罗格雷格博士]

:-)

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




On Sun, Sep 18, 2016 at 5:57 PM +1000, "noonie" 
> wrote:

How to bridge the app/db gap, simple, learn about your enemy & make her your 
friend.

Cooperate, Communicate, Collaborate

Sometimes it works ;-)

--
noonie



On 18 September 2016 at 14:28, Greg Keogh 
> wrote:
GL

If your table design matches your object design, at least one of them is a poor 
design (again I'm talking about serious apps).

Then there's no hope. Game over man! It was easier for Jeff Goldblum to plug 
his laptop into an alien mothership that it is for coders and DBAs to exchange 
data effectively. Perhaps the relational database is a niche evolutionary 
branch that just gained too much popularity in the last 30 years and is now 
overused or incorrectly used and we all take if for granted. Robust RDBs come 
in all sizes and prices, many free, so they're just everywhere and you use them 
without thinking. Codd might regret his legacy!

You must have experienced many situations where some business data doesn't feel 
right in an RDB and you finish up with self-joins and tricks to mimic 
hierarchies, inheritance or represent temporal data. If other people have 
stumbled into this situation and have opted for an effective non-RDB solution 
then I'm keen to hear what happened.

In light of this whole discussion though, in future I'm going to be more 
careful about bridging the code-to-DB gap. Rather than just lazily spiting out 
wads of ORM generated code and throwing it at the DB, I'm going to consider how 
to use views and procs more effectively to do what they do best.

GK

Re: Entity Framework - the lay of the land

[noonie]

How to bridge the app/db gap, simple, learn about your enemy & make her
your friend.

Cooperate, Communicate, Collaborate

Sometimes it works ;-)

-- 
noonie



On 18 September 2016 at 14:28, Greg Keogh  wrote:

> GL
>
> If your table design matches your object design, at least one of them is a
>> poor design (again I'm talking about serious apps).
>>
>
> Then there's no hope. Game over man! It was easier for Jeff Goldblum to
> plug his laptop into an alien mothership that it is for coders and DBAs
> to exchange data effectively. Perhaps the relational database is a niche
> evolutionary branch that just gained too much popularity in the last 30
> years and is now overused or incorrectly used and we all take if for
> granted. Robust RDBs come in all sizes and prices, many free, so they're
> just everywhere and you use them without thinking. Codd might regret his
> legacy!
>
> You must have experienced many situations where some business data doesn't
> feel right in an RDB and you finish up with self-joins and tricks to mimic
> hierarchies, inheritance or represent temporal data. If other people have
> stumbled into this situation and have opted for an effective non-RDB
> solution then I'm keen to hear what happened.
>
> In light of this whole discussion though, in future I'm going to be more
> careful about bridging the code-to-DB gap. Rather than just lazily spiting
> out wads of ORM generated code and throwing it at the DB, I'm going to
> consider how to use views and procs more effectively to do what they do
> best.
>
> *GK*
>

Re: Entity Framework - the lay of the land

[Greg Keogh]

GL

If your table design matches your object design, at least one of them is a
> poor design (again I'm talking about serious apps).
>

Then there's no hope. Game over man! It was easier for Jeff Goldblum to
plug his laptop into an alien mothership that it is for coders and DBAs
to exchange data effectively. Perhaps the relational database is a niche
evolutionary branch that just gained too much popularity in the last 30
years and is now overused or incorrectly used and we all take if for
granted. Robust RDBs come in all sizes and prices, many free, so they're
just everywhere and you use them without thinking. Codd might regret his
legacy!

You must have experienced many situations where some business data doesn't
feel right in an RDB and you finish up with self-joins and tricks to mimic
hierarchies, inheritance or represent temporal data. If other people have
stumbled into this situation and have opted for an effective non-RDB
solution then I'm keen to hear what happened.

In light of this whole discussion though, in future I'm going to be more
careful about bridging the code-to-DB gap. Rather than just lazily spiting
out wads of ORM generated code and throwing it at the DB, I'm going to
consider how to use views and procs more effectively to do what they do
best.

*GK*

Re: Entity Framework - the lay of the land

[罗格雷格博士]

Three other key aspects of this:

If your table design matches your object design, at least one of them is a poor 
design (again I'm talking about serious apps). Yet most ORMs start with this 
assumption.

If you don't bypass your normal object access paths for high speed operations, 
you'll have serious perf issues. It might seem clean to load up a set of 
entities to filter and paginate them on each call. People who do that keep 
generating work for people like me though.

Finally, caching is your friend. I'm called in all the time to help with 
concurrency and scale issues. The #1 way to get a DB to scale is to stop 
talking to it in the first place.

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>

_
From: Greg Low (罗格雷格博士) <g...@greglow.com<mailto:g...@greglow.com>>
Sent: Saturday, September 17, 2016 11:11 AM
Subject: RE: Entity Framework - the lay of the land
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>


And if you have two days free on 28th/29th of this month,  come 
and spend those days on starting to get your head around query performance: 
http://www.sqldownunder.com/Training/Courses/3   (And sorry, 
Melbourne only this year. Might get time mid-next year for a Sydney one).

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: Greg Low (罗格雷格博士)
Sent: Saturday, 17 September 2016 11:04 AM
To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>>
Subject: RE: Entity Framework - the lay of the land

Hey Dave and all,

“The great” -> hardly but thanks Dave.

Look, my issues with many of these ORMs are many. Unfortunately, I spend my 
life on the back end of trying to deal with the messes involved. The following 
are the key issues that I see:

Potentially horrid performance

I’ve been on the back end of this all the time. There are several reasons. One 
is that the frameworks generate horrid code to start with, the second is that 
they are typically quite resistant to improvement, the third is that they tend 
to encourage processing with far too much data movement.

I regularly end up in software houses with major issues that they don’t know 
how to solve. As an example, I was at a start-up software house recently. They 
had had a team of 10 developers building an application for the last four 
years. The business owner said that if it would support 1000 concurrent users, 
they would have a viable business. 5000 would make a good business. 500 they 
might survive. They had their first serious performance test two weeks before 
they had to show the investors. It fell over with 9 concurrent users. The 
management (and in this case the devs too) were panic-stricken.

Another recent example was a software house that had to deliver an app to a 
government department. They were already 4 weeks overdue and couldn’t get it 
out of UAT. They wanted a silver bullet. That’s not the point to then be 
discussing their architectural decisions yet they were the issue.

I was in a large financial in Sydney a while back. They were in the middle of 
removing the ORM that they’d chosen out of their app because try as they might, 
they couldn’t get anywhere near the required performance numbers. Why had they 
called me in? Because before they wrote off 8 months’ work for 240 developers, 
the management wanted another opinion.

Just yesterday I was working on a background processing job that processes a 
certain type of share trades in a UK-based financial service organisation. On a 
system with 48 processors, and 1.2 TB of memory, and 7 x 1 million UK pound 
20TB flash drive arrays, it ran for 48 minutes. During that time, it issued 550 
million SQL batches to be processed and almost nothing else would work well on 
the machine at the same time. The replacement job that we wrote in T-SQL issued 
40,000 SQL batches and ran in just over 2 minutes. I think I can get that to 
1/10 of that with further work. Guess which version is likely to get used now?

Minimal savings yet long term pain

Many of the ORMs give you an initial boost to “getting something done”. But at 
what cost? At best, on most projects that I see, it might save 10% of the 
original development time, on the first project. But as David pointed out in 
his excellent TechEd talk with Joel (and as I’ve seen from so many other 
places), the initial development cost of a project is usually only around 10% 
of the overall development cost. So what are we talking about? Perhaps 1% of 
the whole project? Putting yourself into a long-term restrictive straightjacket 
situation for the sake of a 1% saving is a big, big call. The problem is that 
it’s being 

Re: Entity Framework - the lay of the land

[Stephen Price]

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 <ozdotnet-boun...@ozdotnet.com> on behalf 
of Greg Low (罗格雷格博士) <g...@greglow.com>
Sent: Saturday, 17 September 2016 9:03:49 AM
To: ozDotNet
Subject: RE: Entity Framework - the lay of the land

Hey Dave and all,

“The great” -> hardly but thanks Dave.

Look, my issues with many of these ORMs are many. Unfortunately, I spend my 
life on the back end of trying to deal with the messes involved. The following 
are the key issues that I see:

Potentially horrid performance

I’ve been on the back end of this all the time. There are several reasons. One 
is that the frameworks generate horrid code to start with, the second is that 
they are typically quite resistant to improvement, the third is that they tend 
to encourage processing with far too much data movement.

I regularly end up in software houses with major issues that they don’t know 
how to solve. As an example, I was at a start-up software house recently. They 
had had a team of 10 developers building an application for the last four 
years. The business owner said that if it would support 1000 concurrent users, 
they would have a viable business. 5000 would make a good business. 500 they 
might survive. They had their first serious performance test two weeks before 
they had to show the investors. It fell over with 9 concurrent users. The 
management (and in this case the devs too) were panic-stricken.

Another recent example was a software house that had to deliver an app to a 
government department. They were already 4 weeks overdue and couldn’t get it 
out of UAT. They wanted a silver bullet. That’s not the point to then be 
discussing their architectural decisions yet they were the issue.

I was in a large financial in Sydney a while back. They were in the middle of 
removing the ORM that they’d chosen out of their app because try as they might, 
they couldn’t get anywhere near the required performance numbers. Why had they 
called me in? Because before they wrote off 8 months’ work for 240 developers, 
the management wanted another opinion.

Just yesterday I was working on a background processing job that processes a 
certain type of share trades in a UK-based financial service organisation. On a 
system with 48 processors, and 1.2 TB of memory, and 7 x 1 million UK pound 
20TB flash drive arrays, it ran for 48 minutes. During that time, it issued 550 
million SQL batches to be processed and almost nothing else would work well on 
the machine at the same time. The replacement job that we wrote in T-SQL issued 
40,000 SQL batches and ran in just over 2 minutes. I think I can get that to 
1/10 of that with further work. Guess which version is likely to get used now?

Minimal savings yet long term pain

Many of the ORMs give

RE: Entity Framework - the lay of the land

[Tony Wright]

.
>
>
>
> *Getting stuck with old code*
>
>
>
> SQL Server 2008 added a bunch of new data types. Spatial was one of my
> favourites. When did that get added to EF? Many, many, many years later.
> What could the developers do about it? Almost nothing except very hacky
> workarounds. When you use a framework like this, you are totally at the
> mercy of what its developers feel is important, and that’s if they haven’t
> already lost interest in it. When you code with a tool that was targeted
> cross-DB, you usually end up with a very poor choice of data types. You end
> up with lowest common denominator of everything, or you end up with
> something that doesn’t fit well with the framework.
>
>
>
> Many of the authors of the frameworks quickly lose interest. Do you want
> to be stuck with it?
>
>
>
> *Summary*
>
>
>
> Look, I could go on for hours on this stuff and on what I’ve seen. As I
> mentioned, it depends what you’re building. But if you’re taking
> architectural advice from someone who hasn’t built real systems at scale,
> at least get further opinions. “Oh I don’t want to write all that
> boilerplate code” I hear people say. Sure. I get that but are you incapable
> of code-generation? At least give yourself control over how the code works.
> And that’s mostly a one-time cost. You get to use it again, project after
> project. But at least if you don’t like it, you can fix it.
>
>
>
> I also see a lot of nonsense written about not wanting business logic in
> stored procedures. I love people who have strict rules about that. They
> keep us in business. “We don’t have people with strong T-SQL skills” I hear
> you say. When you have a room full of devs that are clones of each other,
> the lack of T-SQL skills isn’t the problem. The hiring decisions were.
> Yesterday I was in an organisation with around 500 developers. I’d say
> there are almost 2 people who are very data focussed yet data is at the
> core of everything they do. It’s good for me. Those devs can generate poor
> code faster than a handful of us can ever fix it.
>
>
>
> *Future*
>
>
>
> Also worth noting that if you want real performance from upcoming DB
> engines, you might want to rethink that. Even DocumentDB that others have
> mentioned has a concept of a stored procedure within the engine. You write
> them in Javascript. But there’s a reason they are there.
>
>
>
> But in SQL Server 2016, this is even more stark. I have simple examples on
> SQL Server 2016 where a batch of code sent from an app executes in 26
> seconds. If I move the table to in-memory, it runs in 25.5 seconds. If I
> move the code to a natively-compiled stored procedure, it runs in 60
> milliseconds.
>
>
>
> If you are building toy apps ie: a replacement for CardFile, none of this
> matters but I live in a world where it really, really matters. And so do
> the vast majority of software houses that I spend time in.
>
>
>
> Your call.
>
>
>
> 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 *David Connors
> *Sent:* Friday, 16 September 2016 1:20 PM
> *To:* ozDotNet <ozdotnet@ozdotnet.com>
> *Subject:* Re: Entity Framework - the lay of the land
>
>
>
> On Fri, 16 Sep 2016 at 11:56 Greg Keogh <gfke...@gmail.com> wrote:
>
> The people who think that ORMs are a good idea have a code-centric view of
> the world.
>
>
>
> Stored procs!
>
>
>
> I know, right? Finally, someone who shares my enthusiasm!
>
>
>
> [ ... ]
>
>
>
> Databases are unlikely to have a structure that suits coders.
>
>
>
> THIS ^^
>
>
>
> The goal of writing good quality / low TCO software is not to ensure that
> things suit a given coder's predilections along the way.
>
>
>
> What can bridge the "impedance" gap? Something has to.
>
>
>
> I agree. It is called effort.
>
>
>
> It doesn't matter how much you like stored procs, you still have to get
> stuff in and out of them across the gap to the coder's classes. How do
> procs help? Are you proposing that more business logic be moved into procs?
>
>
>
> It isn't a case of me likely stored procs, it is a case of them a
> declarative data tier both in terms of its state and also the paths of
> execution that affect it day to day. The things that change the state of
> the app become entirely deterministic as opposed to whatever BS EF cooks
> up.
>
>
>
> If so, that way lies madness, as you can't easily integrate proc code into
> source control, testing, versioning, builds, etc.
>
>
>
> File -> New -> Project -> SQL Server Database Project. Prepare to be
> amazeballsed.
>
>
>
> I've seen whole apps written in T-SQL, and it's quite frightening.
>
>
>
> I'm not advocating writing whole apps in T-SQL. Stored procs need to be
> short and punchy unless you want to spend your life diagnosing deadlocks.
>
>
>
> David.
>
>
>
>
>
> --
>
> David Connors
> da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363
>

RE: Entity Framework - the lay of the land

[罗格雷格博士]

And if you have two days free on 28th/29th of this month,  come 
and spend those days on starting to get your head around query performance: 
http://www.sqldownunder.com/Training/Courses/3   (And sorry, 
Melbourne only this year. Might get time mid-next year for a Sydney one).

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: Greg Low (罗格雷格博士)
Sent: Saturday, 17 September 2016 11:04 AM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: RE: Entity Framework - the lay of the land

Hey Dave and all,

“The great” -> hardly but thanks Dave.

Look, my issues with many of these ORMs are many. Unfortunately, I spend my 
life on the back end of trying to deal with the messes involved. The following 
are the key issues that I see:

Potentially horrid performance

I’ve been on the back end of this all the time. There are several reasons. One 
is that the frameworks generate horrid code to start with, the second is that 
they are typically quite resistant to improvement, the third is that they tend 
to encourage processing with far too much data movement.

I regularly end up in software houses with major issues that they don’t know 
how to solve. As an example, I was at a start-up software house recently. They 
had had a team of 10 developers building an application for the last four 
years. The business owner said that if it would support 1000 concurrent users, 
they would have a viable business. 5000 would make a good business. 500 they 
might survive. They had their first serious performance test two weeks before 
they had to show the investors. It fell over with 9 concurrent users. The 
management (and in this case the devs too) were panic-stricken.

Another recent example was a software house that had to deliver an app to a 
government department. They were already 4 weeks overdue and couldn’t get it 
out of UAT. They wanted a silver bullet. That’s not the point to then be 
discussing their architectural decisions yet they were the issue.

I was in a large financial in Sydney a while back. They were in the middle of 
removing the ORM that they’d chosen out of their app because try as they might, 
they couldn’t get anywhere near the required performance numbers. Why had they 
called me in? Because before they wrote off 8 months’ work for 240 developers, 
the management wanted another opinion.

Just yesterday I was working on a background processing job that processes a 
certain type of share trades in a UK-based financial service organisation. On a 
system with 48 processors, and 1.2 TB of memory, and 7 x 1 million UK pound 
20TB flash drive arrays, it ran for 48 minutes. During that time, it issued 550 
million SQL batches to be processed and almost nothing else would work well on 
the machine at the same time. The replacement job that we wrote in T-SQL issued 
40,000 SQL batches and ran in just over 2 minutes. I think I can get that to 
1/10 of that with further work. Guess which version is likely to get used now?

Minimal savings yet long term pain

Many of the ORMs give you an initial boost to “getting something done”. But at 
what cost? At best, on most projects that I see, it might save 10% of the 
original development time, on the first project. But as David pointed out in 
his excellent TechEd talk with Joel (and as I’ve seen from so many other 
places), the initial development cost of a project is usually only around 10% 
of the overall development cost. So what are we talking about? Perhaps 1% of 
the whole project? Putting yourself into a long-term restrictive straightjacket 
situation for the sake of a 1% saving is a big, big call. The problem is that 
it’s being decided by someone who isn’t looking at the lifetime cost, and often 
90% of that lifetime cost comes out of someone else’s bucket.

Getting stuck in how it works

For years, code generated by tools like Linq to SQL was very poor. And it knew 
it was talking to SQL Server in the first place. Now imagine that you’re 
generating code and you don’t even know what the DB is. That’s where EF 
started. Very poor choices are often made in these tools. The whole reason that 
“optimize for ad hoc workloads” was added to SQL Server was to deal with the 
mess from the plan cache pollution caused by these tools. A simple example is 
that on the SqlCommand object, they called AddWithValue() to add parameters to 
the parameters collection. That’s a really bad idea. It provides the name of 
the parameter and the value, but no data type. So it used to try to derive the 
data type from the data. So SQL Server would end up with a separate query plan 
for every combination of every length of string for every parameter. And what 
could the developers do to fix it? Nothing. Because it was baked into how the 
framework worked. The framework eventually got changed a bit 

RE: Entity Framework - the lay of the land

[罗格雷格博士]

end up with something that doesn’t fit well 
with the framework.

Many of the authors of the frameworks quickly lose interest. Do you want to be 
stuck with it?

Summary

Look, I could go on for hours on this stuff and on what I’ve seen. As I 
mentioned, it depends what you’re building. But if you’re taking architectural 
advice from someone who hasn’t built real systems at scale, at least get 
further opinions. “Oh I don’t want to write all that boilerplate code” I hear 
people say. Sure. I get that but are you incapable of code-generation? At least 
give yourself control over how the code works. And that’s mostly a one-time 
cost. You get to use it again, project after project. But at least if you don’t 
like it, you can fix it.

I also see a lot of nonsense written about not wanting business logic in stored 
procedures. I love people who have strict rules about that. They keep us in 
business. “We don’t have people with strong T-SQL skills” I hear you say. When 
you have a room full of devs that are clones of each other, the lack of T-SQL 
skills isn’t the problem. The hiring decisions were. Yesterday I was in an 
organisation with around 500 developers. I’d say there are almost 2 people who 
are very data focussed yet data is at the core of everything they do. It’s good 
for me. Those devs can generate poor code faster than a handful of us can ever 
fix it.

Future

Also worth noting that if you want real performance from upcoming DB engines, 
you might want to rethink that. Even DocumentDB that others have mentioned has 
a concept of a stored procedure within the engine. You write them in 
Javascript. But there’s a reason they are there.

But in SQL Server 2016, this is even more stark. I have simple examples on SQL 
Server 2016 where a batch of code sent from an app executes in 26 seconds. If I 
move the table to in-memory, it runs in 25.5 seconds. If I move the code to a 
natively-compiled stored procedure, it runs in 60 milliseconds.

If you are building toy apps ie: a replacement for CardFile, none of this 
matters but I live in a world where it really, really matters. And so do the 
vast majority of software houses that I spend time in.

Your call.

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 David Connors
Sent: Friday, 16 September 2016 1:20 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

On Fri, 16 Sep 2016 at 11:56 Greg Keogh 
<gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote:
The people who think that ORMs are a good idea have a code-centric view of the 
world.

Stored procs!

I know, right? Finally, someone who shares my enthusiasm!

[ ... ]

Databases are unlikely to have a structure that suits coders.

THIS ^^

The goal of writing good quality / low TCO software is not to ensure that 
things suit a given coder's predilections along the way.

What can bridge the "impedance" gap? Something has to.

I agree. It is called effort.

It doesn't matter how much you like stored procs, you still have to get stuff 
in and out of them across the gap to the coder's classes. How do procs help? 
Are you proposing that more business logic be moved into procs?

It isn't a case of me likely stored procs, it is a case of them a declarative 
data tier both in terms of its state and also the paths of execution that 
affect it day to day. The things that change the state of the app become 
entirely deterministic as opposed to whatever BS EF cooks up.

If so, that way lies madness, as you can't easily integrate proc code into 
source control, testing, versioning, builds, etc.

File -> New -> Project -> SQL Server Database Project. Prepare to be 
amazeballsed.

I've seen whole apps written in T-SQL, and it's quite frightening.

I'm not advocating writing whole apps in T-SQL. Stored procs need to be short 
and punchy unless you want to spend your life diagnosing deadlocks.

David.


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

Re: Entity Framework - the lay of the land

[David Connors]

On Fri, 16 Sep 2016 at 13:36 Greg Keogh  wrote:

>
>>
>>> What can bridge the "impedance" gap? Something has to.
>>>
>>
>> I agree. It is called effort.
>>
>
> Come on David ... *effort* into what exactly? What tool, technology, kit,
> gizmo? I need more detail. I'm a coder. I've got to drag stuff in and out
> of databases that I don't own and didn't design and are probably normalized
> to 12th normal form and are works of art. If I don't use an ORM, what the
> hell do I code?
>

Write a structured data access layer as stored procs. Use something like
dapper to wrap them in a class automatically.


> File -> New -> Project -> SQL Server Database Project. Prepare to be
>> amazeballsed.
>>
>
> I've only ever seen a colleague use one of these to write code that
> migrated an Oracle database to SQL Server. I never looked inside it. Am I
> missing something good (for coders)?
>

All the things you said were bad about stored procs are fixed by those
projects. Everything is versioned independently.

David.

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

Re: Entity Framework - the lay of the land

[Craig van Nieuwkerk]

If your project has a database and you are not using a Database Project you
are missing out, and causing yourself a lot of unnecessary pain. It
basically just organises your schema files to make them easy to maintain,
like cs files in a c# project. It has tools to do comparisons and schema
updates that make it essential.

Having said that, if you have a product that you ship to 100's or 1000's of
clients I find using migrations is easier to maintain the database.



>
>
>> File -> New -> Project -> SQL Server Database Project. Prepare to be
>> amazeballsed.
>>
>
> I've only ever seen a colleague use one of these to write code that
> migrated an Oracle database to SQL Server. I never looked inside it. Am I
> missing something good (for coders)?
>
>
>

Re: Entity Framework - the lay of the land

[Greg Keogh]

>
>
>
>> What can bridge the "impedance" gap? Something has to.
>>
>
> I agree. It is called effort.
>

Come on David ... *effort* into what exactly? What tool, technology, kit,
gizmo? I need more detail. I'm a coder. I've got to drag stuff in and out
of databases that I don't own and didn't design and are probably normalized
to 12th normal form and are works of art. If I don't use an ORM, what the
hell do I code?


> File -> New -> Project -> SQL Server Database Project. Prepare to be
> amazeballsed.
>

I've only ever seen a colleague use one of these to write code that
migrated an Oracle database to SQL Server. I never looked inside it. Am I
missing something good (for coders)?

*GK*

Re: Entity Framework - the lay of the land

[David Connors]

On Fri, 16 Sep 2016 at 11:56 Greg Keogh  wrote:

> The people who think that ORMs are a good idea have a code-centric view of
>> the world.
>>
>
> Stored procs!
>

I know, right? Finally, someone who shares my enthusiasm!

[ ... ]


> Databases are unlikely to have a structure that suits coders.
>

THIS ^^

The goal of writing good quality / low TCO software is not to ensure that
things suit a given coder's predilections along the way.


> What can bridge the "impedance" gap? Something has to.
>

I agree. It is called effort.

It doesn't matter how much you like stored procs, you still have to get
> stuff in and out of them across the gap to the coder's classes. How do
> procs help? Are you proposing that more business logic be moved into procs?
>

It isn't a case of me likely stored procs, it is a case of them a
declarative data tier both in terms of its state and also the paths of
execution that affect it day to day. The things that change the state of
the app become entirely deterministic as opposed to whatever BS EF cooks
up.


> If so, that way lies madness, as you can't easily integrate proc code into
> source control, testing, versioning, builds, etc.
>

File -> New -> Project -> SQL Server Database Project. Prepare to be
amazeballsed.


> I've seen whole apps written in T-SQL, and it's quite frightening.
>

I'm not advocating writing whole apps in T-SQL. Stored procs need to be
short and punchy unless you want to spend your life diagnosing deadlocks.

David.


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

Re: Entity Framework - the lay of the land

[Tony Wright]

Even full stack has its problems. It's that whole "generalist" vs
"specialist" argument - sure you can do a bit of everything, but in doing
that, can you actually devote yourself to becoming a master in something?
Pretty hard to do. It's yet another flaw in Agile I think. And that said,
that's what I am, a full-stack developer (although I am also quite strong
in SQL Server, but never really felt inclined to follow that path more
deeply.)

I understand the point of people who have devoted their lives to data, and
having worked in a few large corporates, I can say that the data point of
view and stored procs have merit, in that politically it is much easier to
deliver patches via transactional database update scripts than it is to
redeploy a monolithic application. Being data centric can have its
limitations once the applications get significant though, as a database
itself is one huge brittle API, and when the contract changes and you have
to change your data structure, it can effect everything.

The microservices approach is supposed to get around this somewhat, as
breaking down the monolith and compartmentalising specific purpose chunks
of functionality (which is the high cohesion, low coupling life pattern
again) does give you the ability to deploy those individual slivers
independently of each other if you need to. Great when it works.

Microservices doesn't actually care where you store your data. Each
microservice can store the data wherever the coders decide, and that might
not be a relational database at all. All you do is provide the interface to
the "consumer" and provide a contractual outcome.

Microservices follows more of a domain driven design approach, which, when
done properly, can provide a more flexible, small 'a' agile outcome, and
uncover ideas that can lead to innovative ideas that provide a strategic
advantage, that would otherwise not have been identified in a data centric
environment. And within ddd it is done by sticking to single-directional
relationships between POCO entities by focusing on real world problems.

So you can argue one way or the other, but I see benefits both ways
depending on the circumstances.







On Fri, Sep 16, 2016 at 11:58 AM, Andrew Tobin  wrote:

> Document/Object DBs are kind of the solution for that, however, they still
> need to be managed.
>
> Grow a beard and become "full-stack".
>
> On Fri, Sep 16, 2016 at 11:56 AM, Greg Keogh  wrote:
>
>> The people who think that ORMs are a good idea have a code-centric view
>>> of the world.
>>>
>>
>> Stored procs!
>>
>> Here's the black hole of the argument. To me it's a simple reductionist
>> problem... Clean-shaven code-centric people write real-world apps. Beardy
>> DBAs design databases. Coders need databases. Databases are unlikely to
>> have a structure that suits coders. What can bridge the "impedance" gap?
>> Something has to.
>>
>> It doesn't matter how much you like stored procs, you still have to get
>> stuff in and out of them across the gap to the coder's classes. How do
>> procs help? Are you proposing that more business logic be moved into procs?
>> If so, that way lies madness, as you can't easily integrate proc code into
>> source control, testing, versioning, builds, etc. I've seen whole apps
>> written in T-SQL, and it's quite frightening.
>>
>> Coders need ORMs, heavy or light. I've only used 2 this century, but they
>> simplify and reduce code by a staggering amount. The benefits far outweigh
>> the deficits.
>>
>> I was just discussing this with a colleague and we have made a casual
>> pact that in future apps we will try to meet more halfway across the "gap".
>> He will write procs that aggregate and deep load joined data for complex
>> queries, then my code on the ORM side will query what the proc assembles.
>> We haven't worked out the details of this plan, but I think it lets each
>> part do what they are best at. The procs will assemble and shred data out
>> of tables and the code will work with business objects.
>>
>> *Greg*
>>
>
>

Re: Entity Framework - the lay of the land

[Andrew Tobin]

Document/Object DBs are kind of the solution for that, however, they still
need to be managed.

Grow a beard and become "full-stack".

On Fri, Sep 16, 2016 at 11:56 AM, Greg Keogh  wrote:

> The people who think that ORMs are a good idea have a code-centric view of
>> the world.
>>
>
> Stored procs!
>
> Here's the black hole of the argument. To me it's a simple reductionist
> problem... Clean-shaven code-centric people write real-world apps. Beardy
> DBAs design databases. Coders need databases. Databases are unlikely to
> have a structure that suits coders. What can bridge the "impedance" gap?
> Something has to.
>
> It doesn't matter how much you like stored procs, you still have to get
> stuff in and out of them across the gap to the coder's classes. How do
> procs help? Are you proposing that more business logic be moved into procs?
> If so, that way lies madness, as you can't easily integrate proc code into
> source control, testing, versioning, builds, etc. I've seen whole apps
> written in T-SQL, and it's quite frightening.
>
> Coders need ORMs, heavy or light. I've only used 2 this century, but they
> simplify and reduce code by a staggering amount. The benefits far outweigh
> the deficits.
>
> I was just discussing this with a colleague and we have made a casual pact
> that in future apps we will try to meet more halfway across the "gap". He
> will write procs that aggregate and deep load joined data for complex
> queries, then my code on the ORM side will query what the proc assembles.
> We haven't worked out the details of this plan, but I think it lets each
> part do what they are best at. The procs will assemble and shred data out
> of tables and the code will work with business objects.
>
> *Greg*
>

Re: Entity Framework - the lay of the land

[Greg Keogh]

>
> The people who think that ORMs are a good idea have a code-centric view of
> the world.
>

Stored procs!

Here's the black hole of the argument. To me it's a simple reductionist
problem... Clean-shaven code-centric people write real-world apps. Beardy
DBAs design databases. Coders need databases. Databases are unlikely to
have a structure that suits coders. What can bridge the "impedance" gap?
Something has to.

It doesn't matter how much you like stored procs, you still have to get
stuff in and out of them across the gap to the coder's classes. How do
procs help? Are you proposing that more business logic be moved into procs?
If so, that way lies madness, as you can't easily integrate proc code into
source control, testing, versioning, builds, etc. I've seen whole apps
written in T-SQL, and it's quite frightening.

Coders need ORMs, heavy or light. I've only used 2 this century, but they
simplify and reduce code by a staggering amount. The benefits far outweigh
the deficits.

I was just discussing this with a colleague and we have made a casual pact
that in future apps we will try to meet more halfway across the "gap". He
will write procs that aggregate and deep load joined data for complex
queries, then my code on the ORM side will query what the proc assembles.
We haven't worked out the details of this plan, but I think it lets each
part do what they are best at. The procs will assemble and shred data out
of tables and the code will work with business objects.

*Greg*

Re: Entity Framework - the lay of the land

[Stephen Price]

Entertaining reply, as always David. []


made my morning.


From: ozdotnet-boun...@ozdotnet.com <ozdotnet-boun...@ozdotnet.com> on behalf 
of David Connors <da...@connors.com>
Sent: Friday, 16 September 2016 8:50:30 AM
To: ozDotNet
Subject: Re: Entity Framework - the lay of the land

On Fri, 16 Sep 2016 at 10:33 Greg Keogh 
<gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote:
What do you suggest as an alternative?

Writing stored procedures.

What about the classical problem of "impedance mismatch". You have to carefully 
maintain DataSets or similar and use DataAdapter to fill them, then writing 
data back is a circus trick with the ADO.NET<http://ADO.NET> classes.

Otherwise referred to as doing high quality work.

Then they invented ORMs, why did they do that!? -- GK

I have given this considerable thought over the years. Normally I explain this 
with swear words but I think it boils down to two key factors.

Weltanschauung
The people who think that ORMs are a good idea have a code-centric view of the 
world. Careful declarative design of a data tier is outside of this world-view 
so they see it as overhead (plus they often have to bargain with smelly neck 
beard DBAs).

Free Lunch / Laziness / Lack of care for end result
Developers get excited over the prospect of auto-generation because OMFG look 
at all that code I did not write actually. Most developers don't wear the ops 
cost of their solutions and they certainly don't USE them and consequently 
don't give a toss if some EF-based turd they engineered takes 10 seconds to do 
things that should take 10msec.

Things would be different if the average engineer were forced to walk a mile in 
the average IT pro / end users shoes.

YMMV but I had a good rant on this a few years back: 
https://www.youtube.com/watch?v=YMfRahO8fLo (jesus that was 6 years ago). I 
have softened my stance on Agile somewhat since then.

Good outcomes always take more effort and energy. The universe has been that 
way for 13.8 billion years and isn't going to change any time soon.

David.

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

Re: Entity Framework - the lay of the land

[Craig van Nieuwkerk]

PetaPoco or Dapper are not really an ORM like EF or NHibernate. You can
write SQL or a stored proc and all it really does is map it to a POCO for
ease of use in the C# code. I have not really touched a DataSet or
DataAdapter directly for years.

On Fri, Sep 16, 2016 at 10:51 AM, Greg Keogh  wrote:

> Using something like PetaPoco makes that pretty easy.
>>
>
> Okay, I never saw that before. It's still and ORM, albeit a small one. At
> a glance at the home page, you're coding SQL statements inside code (tight
> coupling), it's not a LINQ provider at all, and it uses T4 templates (like
> EF does anyway). So overall, it's cute but I can't imagine using this
> in heavyweight projects -- *GK*
>

Re: Entity Framework - the lay of the land

[Tony Wright]

They did it to reduce the number of errors found at runtime. The errors are
found at compile time with orms.

Dapper is another micro-orm that's worth looking at.

On 16 Sep 2016 10:40 AM, "Craig van Nieuwkerk"  wrote:

> Using something like PetaPoco makes that pretty easy.
>
>
>
>> What about the classical problem of "impedance mismatch". You have to
>> carefully maintain DataSets or similar and use DataAdapter to fill them,
>> then writing data back is a circus trick with the ADO.NET classes. Then
>> they invented ORMs, why did they do that!? -- *GK*
>>
>
>

Re: Entity Framework - the lay of the land

[Andrew Tobin]

I haven't had significant problems that I haven't been able to fix.  That
said, I think they're marking the current as Stable and just working on
features of EF Core now, which isn't as complete by far yet.

On Fri, Sep 16, 2016 at 10:40 AM, Craig van Nieuwkerk 
wrote:

> Using something like PetaPoco makes that pretty easy.
>
>
>
>> What about the classical problem of "impedance mismatch". You have to
>> carefully maintain DataSets or similar and use DataAdapter to fill them,
>> then writing data back is a circus trick with the ADO.NET classes. Then
>> they invented ORMs, why did they do that!? -- *GK*
>>
>
>

Re: Entity Framework - the lay of the land

[Greg Keogh]

>
> Using something like PetaPoco makes that pretty easy.
>

Okay, I never saw that before. It's still and ORM, albeit a small one. At a
glance at the home page, you're coding SQL statements inside code (tight
coupling), it's not a LINQ provider at all, and it uses T4 templates (like
EF does anyway). So overall, it's cute but I can't imagine using this
in heavyweight projects -- *GK*

Re: Entity Framework - the lay of the land

[David Connors]

On Fri, 16 Sep 2016 at 10:33 Greg Keogh  wrote:

> What do you suggest as an alternative?
>>
>> Writing stored procedures.
>>
>
> What about the classical problem of "impedance mismatch". You have to
> carefully maintain DataSets or similar and use DataAdapter to fill them,
> then writing data back is a circus trick with the ADO.NET classes.
>

Otherwise referred to as doing high quality work.


> Then they invented ORMs, why did they do that!? -- *GK*
>

I have given this considerable thought over the years. Normally I explain
this with swear words but I think it boils down to two key factors.

*Weltanschauung*
The people who think that ORMs are a good idea have a code-centric view of
the world. Careful declarative design of a data tier is outside of this
world-view so they see it as overhead (plus they often have to bargain with
smelly neck beard DBAs).

*Free Lunch / Laziness / Lack of care for end result*
Developers get excited over the prospect of auto-generation because OMFG
look at all that code I did not write actually. Most developers don't wear
the ops cost of their solutions and they certainly don't USE them and
consequently don't give a toss if some EF-based turd they engineered takes
10 seconds to do things that should take 10msec.

Things would be different if the average engineer were forced to walk a
mile in the average IT pro / end users shoes.

YMMV but I had a good rant on this a few years back:
https://www.youtube.com/watch?v=YMfRahO8fLo (jesus that was 6 years ago). I
have softened my stance on Agile somewhat since then.

Good outcomes always take more effort and energy. The universe has been
that way for 13.8 billion years and isn't going to change any time soon.

David.

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

RE: Entity Framework - the lay of the land

[David Smith]

Or Dapper (https://github.com/StackExchange/dapper-dot-net)

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Craig van Nieuwkerk
Sent: Friday, 16 September 2016 12:40 p.m.
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

Using something like PetaPoco makes that pretty easy.



What about the classical problem of "impedance mismatch". You have to carefully 
maintain DataSets or similar and use DataAdapter to fill them, then writing 
data back is a circus trick with the ADO.NET<http://ADO.NET> classes. Then they 
invented ORMs, why did they do that!? -- GK

Re: Entity Framework - the lay of the land

[Craig van Nieuwkerk]

Using something like PetaPoco makes that pretty easy.



> What about the classical problem of "impedance mismatch". You have to
> carefully maintain DataSets or similar and use DataAdapter to fill them,
> then writing data back is a circus trick with the ADO.NET classes. Then
> they invented ORMs, why did they do that!? -- *GK*
>

Re: Entity Framework - the lay of the land

[Greg Keogh]

>
> What do you suggest as an alternative?
>
> Writing stored procedures.
>

What about the classical problem of "impedance mismatch". You have to
carefully maintain DataSets or similar and use DataAdapter to fill them,
then writing data back is a circus trick with the ADO.NET classes. Then
they invented ORMs, why did they do that!? -- *GK*

Re: Entity Framework - the lay of the land

[David Connors]

On Fri, 16 Sep 2016 at 10:08 Greg Keogh  wrote:

> What type of projects is EF not suitable for?
>>>
>> Ones that run on computers.
>>
>
> What do you suggest as an alternative?
>

Writing stored procedures.

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

Re: Entity Framework - the lay of the land

[Greg Keogh]

>
> What type of projects is EF not suitable for?
>>
> Ones that run on computers.
>

What do you suggest as an alternative?

*GK*

Re: Entity Framework - the lay of the land

[David Connors]

On Fri, 16 Sep 2016 at 09:55 David Apelt  wrote:

> What type of projects is EF not suitable for?
>
Ones that run on computers.

*Mr Connors thinks back to all the times he's been told he is wrong on this
list for saying ORMs and their ilk are sh!t*

David.

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