Sitat av
nso
Takk for den. Visste ikke om denne funksjonen. Tviler på jeg kommer til å ta det i bruk ettersom det er en del logikk i koden som ikke bryr seg om slettet-status, og jeg føler det blir litt ekkelt å ha et "skjult" filter som man da må vite eksisterer for å evt overstyre. Føler allerede at jeg synder litt ved å ha .AsNoTracking() som default :shrug:
Har noe lignende problem på et prosjekt, der løser vi dette med at vi har en metode i database contexten som gir deg en
Queryable i retur, med et ferdig where filter. Entitetene vi vil ha dette filteret på arver av en
SoftDeleteEntityBase klasse, så med litt generics så hiver vi på filteret når du spørr på den entiteten. Metoden ser ca slik ut:
Kode
public IQueryable<TEntityType> Queryable<TEntityType>(bool filterOnIsDeleted = true) where TEntityType : class
=> filterOnIsDeleted && typeof(SoftDeleteEntityBase).IsAssignableFrom(typeof(TEntityType))
? Set<TEntityType>().Where($"{nameof(SoftDeleteEntityBase.IsDeleted)} == false")
: Set<TEntityType>();
Den slenger på filteret på alle klasser som arver av
SoftDeleteEntityBase, men kan overstyres der man vil ved å sette
filterOnIsDeleted som tile false. For entiteter som ikke arver etter den base klassen, så får du bare en vanlig
Queryable i retur. Dette ender opp som en litt sånn halveis løsning imellom det lor3ntz foreslår og ingenting. Det blir da litt mer synlig at det er noe som skjer med
Queryable siden man ikke går rett på
DbSet propertyen. Men mer at den kommer ikke til å filtrere på joins, bare på den entiteten
Queryable "starter" på.