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 <[email protected]> wrote:
> On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士) <[email protected]> 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
> [email protected] | @davidconnors | LinkedIn | +61 417 189 363
>
