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 <[email protected]
<mailto:[email protected]>> wrote:
On Tue, 20 Sep 2016 at 13:59 Greg Low (罗格雷格博士) <[email protected]
<mailto:[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
