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