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

Reply via email to