Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

    EventId uniqueidentifier
    EventName varchar

    UserId uniqueidentifier
    Name varchar

TABLE EventSubscription

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)
    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()

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?

share|improve this question

2 Answers 2

up vote 2 down vote accepted

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

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();
        case EventType.Sleeping:
            imp = new SleepingEvent();
        case EventType.FooBar:
            imp = new FooBarEvent();
    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.

share|improve this answer
Hmm, I have a restriction that each table has to use a uniqueidentifier column as the primary key. Using your method would imply that I'm adding a second key (int) but I guess that's not the end of the world. If I did that, I could make it a discriminator for the NHibernate mapping, and let it auto-generate the correct sub-class. I think that makes yours the right answer. –  Scott Whitlock Nov 8 '12 at 22:06

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. yuml for subscriptions

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.