When is it OK to blur the abstraction between data and logic?

Question

I mean referring to specific database rows by their ID, from code, or specifying a class name in the database. Example:

You have a database table called SocialNetwork. It's a lookup table. The application doesn't write or or delete from it. It's mostly there for database integrity; let's say the whole shebang looks like this:

SocialNetwork table:

Id | Description
-----------------------------
1  | Facebook
2  | Twitter

SocialNetworkUserName table:

Id | SocialNetworkId | Name
---------------------------------------------------
1  | 2               | @seanssean
2  | 1               | SeanM

In your code, there's some special logic that needs to be carried out for Facebook users. What I usually do is make either an enum or some class constants in the code to easily refer to it, like:

if (socailNetwork.Id == SocialNetwork.FACEBOOK ) // SocialNetwork.FACEBOOK = 1
  // special facebook-specific functionality here

That's a hard-coded database ID. It's not a huge crime since it's just referencing a lookup table, but there's no longer a clean division between data and logic, and it bothers me.

The other option I can think of would be to specify the name of a class or delegate in the database, but that's even worse IMO because now you've not only broken the division between data and logic, but you've tied yourself to one language now.

Am I making much ado about nothing?

Answer 1

I don't see the problem.

At some point your code needs to do things. Facebook is a real social network, with its own real API, and you want it to do Facebook-specific things in your code. Unless your tasks are trivial, to put all of the Facebook-specific stuff in the database would mean a headache in your code. (What's the equivalent of "Like" in Twitter, for example?)

If the Facebook entry isn't in your database, then the Facebook-specific code won't be executed. You can do that much.

Answer 2

Yep, but with the caveat that "it depends." It's unlikely to change, but.

Storing the name of a class or delegate is probably bad, but storing a token used by a class or delegate factory isn't, because it's language-neutral--but you'll always have the problem of having to maintain the connection somewhere. Unless you have a table of language-specific things tied to that table, at which point I believe you'd be shot.

Rather than keep the constant comparison in mainline code, IMO this kind of situation is nice for a factory/etc. pattern, enum lookup, etc. to implement network-specific class lookup/behavior. The mainline code shouldn't have to care how it's implemented, which it does right now--that part is a genuine concern.

With the caveat that ultimately it may never matter. If it were me, I'd at least de-couple the mainline code, because stuff like that makes me twitchy.