Don't SUCK With Entity Framework - Change Tracking - Performance Tips Part 8

แชร์
ฝัง
  • เผยแพร่เมื่อ 13 ม.ค. 2025

ความคิดเห็น • 6

  • @inc06nito
    @inc06nito 3 ปีที่แล้ว

    Thank you so much sir. This was really helpful 🤠

  • @gralexp
    @gralexp 4 ปีที่แล้ว +1

    Maybe it is better to create a constructor for db context with Boolean parameter defaulted to true, and change the tracking based on that? Or "false" - whatever is your most common use case.

    • @CodeItUpByAMBITIONED
      @CodeItUpByAMBITIONED  4 ปีที่แล้ว +1

      It will not work with the dependency injection. The AsNoTracking extension method is good enough.

    • @gralexp
      @gralexp 4 ปีที่แล้ว

      @@CodeItUpByAMBITIONED ok, makes sense. Thanks

  • @KrisLyubenov
    @KrisLyubenov 5 ปีที่แล้ว

    Another great video from the "Dont SUCK with EF" series thanks Ivo :)
    I think it would've been good to mention some real life cases (based on your knowledge/experience) in which we can benefit from turning of the "Change Tracking".
    From my personal experience I can say that maybe a good place to disable EF Change Tracking will be in case you have splitted your database to write and read replicas and you use different EF contexts for each, then it seems logical to disable Change Tracking on the read replica, wdyt?

    • @CodeItUpByAMBITIONED
      @CodeItUpByAMBITIONED  5 ปีที่แล้ว +1

      Thank you for the nice words! Basically, each case is different. If your database query is only related for read operations, you should disable it. This is why I did not mention any specific code examples, because it depends on the business logic.