Styjun

I have a controller that modifies appointments in a calendar. I want to use my SignalR hub to notify users à la "User X changed appointmentTitle: List: Property OriginalValue NewValue"

I'm a beginner in C# (Syntax-wise it's ok, but OOP concepts are new); I'm trying to use events to achieve the above.
Below are the handlers and arguments, an extract from the controller and a summary of my questions.

Code is abbreviated!

EventArgs

 public class AppointmentChangeEventArgs : EventArgs
 
 public EntityState AppointmentState = EntityState.Unchanged;
 public EntityEntry Entity = null;
 public ScheduleData Appointment = null;
 

EventHandler

 // maybe this could be just one, and let the consumer decide based on EntityState?
 public EventHandler<AppointmentChangeEventArgs> AppointmentChanged;
 public EventHandler<AppointmentChangeEventArgs> AppointmentAdded;
 public EventHandler<AppointmentChangeEventArgs> AppointmentRemoved;

 protected virtual void OnAppointment(AppointmentChangeEventArgs appointmentChangeEventArgs)
 
 switch (appointmentChangeEventArgs.AppointmentState)
 
 case EntityState.Added:
 AppointmentAdded?.Invoke(this, appointmentChangeEventArgs);
 break;
 case EntityState.Deleted:
 AppointmentRemoved?.Invoke(this, appointmentChangeEventArgs);
 break;
 case EntityState.Modified:
 AppointmentChanged?.Invoke(this, appointmentChangeEventArgs);
 break;
 default:
 break;
 
 

Controller

public async Task<IActionResult> Batch([FromBody] ScheduleEditParameters param)
 switch (param.Action) 
 case "insert":
 await _dbContext.Appointments.AddAsync(appointment);
 break;
 case "update":
 // .. get Appointment from DB
 appointment.Subject = value.Subject;
 appointment.StartTime = value.StartTime;
 // ...
 case "remove": 
 // .. get Appointment from DB
 _dbContext.Appointments.Remove(appointment);
 
 var modifiedEntries = _dbContext.ChangeTracker
 .Entries()
 .Where(x => x.State != EntityState.Unchanged && x.State != EntityState.Detached)
 .Select(x => new AppointmentChangeEventArgs() Entity = (EntityEntry) x.Entity, AppointmentState = x.State, Appointment = appointment )
 .ToList();

 if (modifiedEntries.Any())
 
 var notificationService = new NotificationService(signalRHub, notificationLogger);
 AppointmentAdded += notificationService.OnAppointmentChanged;
 AppointmentChanged += notificationService.OnAppointmentChanged;
 AppointmentRemoved += notificationService.OnAppointmentChanged;
 
 await _dbContext.SaveChangesAsync();

Questions

• Is it ok to use EntityEntry and EntityState in event arguments?


• for each modified Entry, I can obtain _dbContext.Entry(modifiedEntry).Properties.Where(x => x.IsModified).ToList(); - but does this belong in the NotificationService class? In order to do that, I'd also need to pass the DbContext over to NotificationService.


• Might there be a simpler way to achieve this? Adding and Removing handlers are easy ("User X has added|removed ... appointment Title"), but in order to figure out the exact changes I'll have to look at the modified properties.

I'd be grateful if you could provide an insight into how you would structure & handle this task. Thank you.

To start off, I would generally recommend you not to use events here. Events are something that may sound very useful but due to the way they work (synchronously), they aren’t really the best way to achieve this in a web context, especially in a primarily asynchronous framework like ASP.NET Core.

Instead, I would recommend you to simply declare your own type, e.g. IAppointmentChangeHandler like this:

public interface IAppointmentChangeHandler

 Task AddAppointment(ScheduleData appointment);
 Task UpdateAppointment(ScheduleData appointment);
 Task RemoveAppointment(ScheduleData appointment);

Your NotificationService can just implement that interface to be able to handle those events (obviously just send whatever you need to send there):

public class NotificationService : IAppointmentChangeHandler

 private readonly IHubContext _hubContext;

 public NotificationService(IHubContext hubContext)
 
 _hubContext = hubContext;
 

 public AddAppointment(ScheduleData appointment)
 
 await _hubContext.Clients.InvokeAsync("AddAppointment", appointment);
 

 public UpdateAppointment(ScheduleData appointment)
 
 await _hubContext.Clients.InvokeAsync("UpdateAppointment", appointment);
 

 public RemoveAppointment(ScheduleData appointment)
 
 await _hubContext.Clients.InvokeAsync("RemoveAppointment", appointment);
 

And inside of your controller, you just inject that IAppointmentChangeHandler then and call the actual method on it. That way you have both the controller and the notification service completely decoupled: The controller does not need to construct the type first and you also do not need to subscribe to some events (which you would also have to unsubscribe from at some point again btw). And you can leave the instantiation completely to the DI container.

To answer your individual questions:

Is it ok to use EntityEntry and EntityState in event arguments?

I would avoid using it in a context outside of your database. Both are an implementation detail of your database setup, since you are using Entity Framework here. Not only would this couple your event handlers strongly with Entity Framework (meaning that everyone that wanted to be an event handler would need to reference EF even if they didn’t do anything with it), you are also leaking possibly internal state that may change later (you don’t own the EntityEntry so who knows what EF does with it afterwards).

for each modified Entry, I can obtain _dbContext.Entry(modifiedEntry).Properties.Where(x => x.IsModified).ToList();

If you look at your code, you are first calling Add, Update or Remove on your database set; and then you are using some logic to look at some internal EF stuff to figure out the exact same thing really. You could make this a lot less complex if you constructed the AppointmentChangeEventArgs within those three switch cases directly.

but does this belong in the NotificationService class? In order to do that, I'd also need to pass the DbContext over to NotificationService.

Does a notification service have anything to do with a database? I would say no; unless you are persisting those notifications into the database. When I think about a notification service, then I expect to be able to call something on it to actively trigger a notification, instead of having some logic within the service to figure out what notifications it could possibly trigger.

Might there be a simpler way to achieve this? Adding and Removing handlers are easy ("User X has added|removed ... appointment Title"), but in order to figure out the exact changes I'll have to look at the modified properties.

Think about it in the simplest way first: Where do you update the values of the database entity? Within that update case. So at that point, where you are copying over values from the passed object, you can also just check which properties you are actually changing. And with that, you can record easily which properties you need to notify about.

Decouple this completely from EF and you will be a lot more flexible in the long run.