How do you handle objects that need custom behavior, and need to exist as an entity in the database?

Question

For a simple example, assume your application sends out notifications to users when various events happen. So in the database I might have the following tables:

TABLE Event
    EventId uniqueidentifier
    EventName varchar

TABLE User
    UserId uniqueidentifier
    Name varchar

TABLE EventSubscription
    EventUserId
    EventId
    UserId

The events themselves are generated by the program. So there are hard-coded points in the application where an event instance is generated, and it needs to notify all the subscribed users.

So, the application itself doesn't edit the Event table, except during initial installation, and during an update where a new Event might be created.

At some point, when an event is generated, the application needs to lookup the Event and get a list of Users. What's the best way to link the event in the source code to the event in the database?

Option 1:

Store the EventName in the program as a fixed constant, and look it up by name.

Option 2:

Store the EventId in the program as a static Guid, and look it up by ID.

Extra Credit

In other similar circumstances I may want to include custom behavior with the event type. That is, I'll want subclasses of my Event entity class with different behaviors, and when I lookup an event, I want it to return an instance of my subclass.

For instance:

class Event
{
    public Guid Id { get;  }
    public Guid EventName { get;  }
    public ReadOnlyCollection<EventSubscription> EventSubscriptions { get; }
    public void NotifySubscribers()
    {
        foreach(var eventSubscription in EventSubscriptions)
        {
            eventSubscription.Notify();
        }
        this.OnSubscribersNotified();
    }
    public virtual void OnSubscribersNotified() {}
}

class WakingEvent : Event
{
    private readonly IWaker waker;
    public WakingEvent(IWaker waker)
    {
        if(waker == null) throw new ArgumentNullException("waker");
        this.waker = waker;
    }

    public override void OnSubscribersNotified()
    {
        this.waker.Wake();
        base.OnSubscribersNotified();
    }
}

So, that means I need to map WakingEvent to whatever key I'm using to look it up in the database. Let's say that's the EventId. Where do I store this relationship? Does it go in the event repository class? Should the WakingEvent know declare its own ID in a static member or method?

...and then, is this all backwards? If all events have a subclass, then instead of retrieving events by ID, should I be asking my repository for the WakingEvent like this:

public T GetEvent<T>() where T : Event
{
    ... // what goes here?
}

I can't be the first one to tackle this. What's the best practice?

Answer 1

I assume data in Event is truly static, not dynamic. If that's the case an enum could represent the event types. Have both the name and ID match that of the database if possible. At least 1 should match.

enum EventType
{
    Waking = 1, //it would be nice if both enum's name/int matched DB name/ID
    Sleeping,
    FooBar
}

To get the Event object pass an enum to a factory method.

IEvent getImp(EventType type)
{
    IEvent imp = null;

    switch (type)
    {
        case EventType.Waking:
            imp = new WakingEvent();
            break;
        case EventType.Sleeping:
            imp = new SleepingEvent();
            break;
        case EventType.FooBar:
            imp = new FooBarEvent();
            break;
    }
    return imp;
}

It may feel "wrong" because everything is hard-coded into the app. But this is assuming the behavior cannot be data driven. Random complex behavior cannot be defined as data unless the data itself is imperative code.

Answer 2

No this is a common subsystem of larger applications, I call it Alerts and Notifications. The Event and Subscriber entities you mentioned are a starting point.

Here we have a simple diagram for the core of the system. You have an EventType, which just describes the various events that can be raised by the system. A subscription (which may have hanging off of it various subscription types, e.g. Email, SMS, etc.). When an event is generated, the system looks at that event's type and generates an alert for each subscription.

The tricky part is like you said, how to create a hierarchy of events. Event Type is what is known in the Object Modeling world as a Descriptor. Descriptors have an inherent knowledge of how to generate the type of object they are describing. That is, they act as object factories. We used an ORM trick where we stored the fully qualified name of the Event subclasses in the EventType table for each type. Thus when we had an instance of an EventType, it would return subclass of the Event via Reflection.

Most O/RMs support mapping a hierarchy of classes to a database (at least in the .NET world).

There is a lot more that could be said about implementing an alert and notification system. But I'll leave the discussion open for you to ask any follow-up questions.