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 (罗格雷格博士) <[email protected]> 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:* [email protected] [mailto:ozdotnet-bounces@ > ozdotnet.com] *On Behalf Of *David Rhys Jones > *Sent:* Tuesday, 20 September 2016 7:20 PM > *To:* ozDotNet <[email protected]> > *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 <[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 > > >
