is there a best practice to attach email notifications to some methods without editing the methods inner code?

I am working on a website and we will need to send the user some email notifications when some actions happen on the website, such as if someone else sent the user a message or invite开发者_开发技巧 him to an event.

Is there a standard good way to attach a notification to any method without changing the method code?

For example I was thinking if I can put an attribute on the method this attribute will make this method to call the notification module with some parameters.

note: I am working on an ASP.Net MVC 3 website, using entity framework codefirst.

---

I do not believe there is a standard process.

Aspect Oriented approaches (such as attributes) can be handy only if there are used in conjunction with AOP frameworks (such as AspectSharp) or when used on the MVC Action itself: you can use action filters to achieve the requirement and send use the notification if the events are mapped to MVC actions.

---

Event Listeners. You do have to change the code, but you don't actually send the email within the code.

Basically, any code that does stuff that other code might be interested in has hooks so that listeners can attach to it and listen for events.

In Pseudo-java:

public class OrderProcessor {
  protected final List<OrderProcessorListener> listeners = new ArrayList<OrderProcessorListener>();

  public void addListener(OrderProcessorListener orderProcessorListener) {
    listeners.add(orderProcessorListener);
  }

  public void notifyListeners(OrderProcessorEvent event) {
    for(OrderProcessorListener listener : listeners) {
      listener.handle(event);
    }
  }

  public void randomMethod() {
    // ... do stuff
    notifyListeners(new SomeEvent(...)); // notify listeners
  }

  public interface OrderProcessorListener {
    public void handle(OrderProcessorEvent event);
  }
}

then, other interested code can do...

public class EmailSender implements OrderProcessorListener {
  public void handleEvent(OrderProcessorEvent event) {
    // do whatever...
  }
}

When you construct your OrderProcessor and your EmailSender, you then add the EmailSender as a listener and voila. You can use this pattern everywhere you need to react to actions from a piece of code- and you don't need to put the actions in the same code...

---

Would be pretty hard without any change to the original code. How would you know an action succeeded? And what type of notification should be sent, to whom, etc.

If not changing the original code is a must, you could do it in a hacky way: add a global filter, inspect the controller name, action name, the action result, and maybe you could decide from those parameters if an email should be sent. But this would be extremely fragile, and a maintenance nightmare.

Unless your notifications are extremely simple, like always send e-mail to all event attendees, if any modification is done to the event. But that could cover only some of the basic use-cases...

IMO it would be better if you integrated sending notifications into your existing code. If you extend the meaning of a repository (and you use one) to "take database actions, and anything else related to creation/update/delete of an object". No changes to controller actions, and your EventRepository.Create/Modify methods would know already have all the parameters to send the notifications...