Add EntityFrameworkCore.Triggered in the tools & extensions list

[koenbeuk]

I've recently published v2 of a project called EntityFrameworkCore.Triggered which lets you code triggers (similar to SQL Server triggers) within an EF domain. It allows you to run arbitrary code in response to changes within your SaveChanges cycle (both before and after SaveChanges happened). Its somewhat similar to Ramses which is already listed in the docs, but on steroids, as it supports full DI integration, Async out of the box, as well as recursion (a BeforeSave trigger could modify the ChangeSet which in return would invoke additional triggers). Given that the plugin is designed to solely add-on to the foundation of EFCore while minimising the number of new concepts introduced, I think its a fair candidate to be noted in the docs. Please consider adding it and driving traffic to the project.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8875eb79-99ff-662b-c189-86eb8cdb5488
• Version Independent ID: fa03a7fa-1922-7aa1-acda-b0d216ef37cb
• Content: Tools & Extensions - EF Core
• Content Source: entity-framework/core/extensions/index.md
• Product: entity-framework
• Technology: entity-framework-core
• GitHub Login: @ErikEJ
• Microsoft Alias: avickers

[roji]

Out of curiosity, how would you compare this to the SaveChanges events and interceptors introduced in EF Core 5.0?

[koenbeuk]

@roji
In short: SaveChanges interception intercepts calls to SaveChanges whereas triggers Intercepts changes on individual entities.

Triggers are fundamentally higher up the stack. They are individual units of work that are strongly typed and are invoked for specific entities and change types (e.g. intercepting a modified Customer entity). Interceptors are much lower in the stack and a more generalised driver invoked for calls To SaveChanges. In fact, since V2 of this project, Triggers are built on top of SaveChanges interception, before (v1, targeting EFCore 3.1 required overriding SaveChanges/SaveChangesAsync or implementing the TriggeredDbContext).

Some advantages of triggers over SaveChanges interception:

• There is no easy DI solution for SaveChanges events/interceptor. Interceptors are resolved through EF's internal DI container which has no access to get a hold of your user services.
• Interceptors are always called, Triggers are called only if there is a type match (IBeforeSaveTrigger< Customer> will only be invoked for added/modified/removed customers). The trigger context then contains information about the current state of the entity, the change type as well as in case of a Modified entity, the state of the entity before that change. To get this to work manually with SaveChangesInterceptors is a bit of a hassle. (Triggers can also listen for base types or interfaces).
• Interceptors run once for each SaveChanges lifecycle while triggers run recursively (A IBeforeSaveTrigger may change the context further (E.g. add additional entities)), which in turn will recursively raise triggers interested in that change.
• Triggers can be registered and are invoked in a predictable order so that you can ensure that one trigger runs before another trigger.
• Triggers go beyond simply hooking into SaveChanges as there are also extensions for Transaction triggers (e.g. I[Before/After]CommitTrigger).

Perhaps a good example for seeing the power of triggers: https://github.com/koenbeuk/EntityFrameworkCore.Triggered/tree/master/samples/v2/3%20-%20StudentManagerAspNetCore

[ajcvickers]

@koenbeuk Feel free to submit a PR for this. We don't typically add these things ourselves, we just take PRs from the community. Make sure to keep the formatting. etc. consistent with other extensions in the page.