Closed wonea closed 7 years ago
I'm glad this issue was raised as it's something I've been thinking about for months. I've been leaning toward using a message queue to push the events across application domains and even machines. Having the ability to see changes across a clustered application would be much more valuable.
Where I got stuck was thinking too much about how to make the events ORM agnostic. Essentially, I would look at the top five ORMs (dapper, EF, NHibernate, etc.) and make sure they're supported (where possible) for generating and responding o events.
I see the scope of this project could swell massively. Providing a message queue could complicate things, and at that point people might start thinking they could put their own data links together.
Application -> EF -> Database
-> Messaging tool -> Application 2
For my own needs I've played around with refreshing EF
https://github.com/wonea/EFAutoRefresh
Perhaps create separate packages for each provider?
EntityFramework.Trigger.SqlServer EntityFramework.Trigger.MySQL
Yes it would be a decent undertaking. That thinking led me to consider an even larger scope project which integrates data changes with updating view-models. Like a Meteor.NET (at least some of the plumbing).
I would like to use EntityFramework.Triggers across multiple instances, would it be possible to raise an event and another instance to capture this? Similar to what a service broker would do.