Does an in-code enumeration provide a stronger domain model than a static table?

Question

Does an in-code enumeration provide a stronger domain model than a static database table?

As an example, say I have an Marble entity, with a Color attribute. The color attribute has a finite set of possible values—say red, green, blue. Say the database team recommends having a static S_ValidColors table, to the effect of:

-----------------------
| ColorId | ColorName |
-----------------------
|    0    |    Red    |
-----------------------
|    1    |   Green   |
-----------------------
|    2    |    Blue   |
-----------------------

Whereas I'm thinking more along the lines of (this is just a sketch for the general concept):

public class Color {
    public static const Color Red = Color(0);
    public static const Color Green = Color(1);
    public static const Color Blue = Color(2);

    private Color(uint typeCode) {
        ...
    }
    ...
}

Aside from the question of which is better (which probably depends on any number of other factors not represented here), is this a question that touches how strong the domain model is? Is one way more anemic than the other?

Answer 1

It entirely depends on the use of the enum. If they are going to change often then in the DB is better, you don't want to recompile and redeploy once a week because Joe changed his favorite color again. If the enum is more fixed then hard coding it will be better, it is easier to reason about and less likely to get broken. Do you need to access it from stored procedures? Might be a good idea to have it in the database where both stored procs and regular code can access it. You really don't want the headache of maintaining two different versions of the same thing. What does the logic that uses this enum look like? There are situations where either option is more practical.

As far as the anemic domain model thing goes I don't think it applies. As long as the domain model enforces the domain model's rules and processes, then the domain model is not anemic. Storing values in the DB just makes them more dynamic and easier to change(which could be a bad thing given the right assumptions.)

Answer 2

We had exactly same discussion few years back at my old work. In the end, we choose the 2nd option. The reasoning is :

When you change something in DB, you expect those changes to work without having to re-deploy the application. But in case of these kind of enumerations, the code might depend on the fact, that there are exact values for this enumeration. Lets say you have switch that uses this enumeration and if invalid value is provided, it throws an exception. By having the values hard-coded, you can ensure your code doesn't cause errors around those enums. Even when some "clever" administrator decides to add their own values.

Of course, this depends. If you are only working with list of all values, then this doesn't really make sense. But it does make sense if you work with specific individual values in your code.

Also, having to read those values from DB can impact performance or create complex code, even thought they are not really changing.

Answer 3

Creating a static database model can provide some difficulties without any benefits:

• Reading from a database will be slower;
• If the color values change update deployment will be more difficult since you won't only need to update the source, but also the database;
• Like Euphoric mentioned, you will be more prone to errors in case some of the objects in the DB are missing or modified.

So if the user is not expected to add his own colors, I don't see any reason to store them in a database.