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 >