2

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?

Sean
  • 1,668
  • 1
  • 18
  • 28
  • You are asking about architecture, which is good. The truth is that you should keep on looking further. A good place to start is to search around for patterns and practices so you know what techniques are out there. Specifically you may start thinking about weather it's really a good idea to have a single file with a bunch of switch cases, an inheritance model, or just plain old delegates set during construction. – JSWork Oct 06 '11 at 16:37
  • 1
    JSWork I agree; the single file with the switch statements was just to have a simple example to illustrate my question, the heart of which is: Is it OK for my code to specifically refer to a row from my database by ID? – Sean Oct 06 '11 at 20:32
  • I don't know which answer to accept! You both provided good answers IMO! – Sean Oct 08 '11 at 21:16

2 Answers2

1

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.

Dave Newton
  • 158,873
  • 26
  • 254
  • 302
  • Yeah, I agree that it should be a factory which hands back a concrete implementation of an agreed-upon interface. (Was just tryin' to keep the example simple...) Thanks for the response! – Sean Oct 06 '11 at 16:39
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.

John
  • 15,990
  • 10
  • 70
  • 110
  • The "problem" is that the mainline code is depending on magic numbers, and the link between the magic numbers and functionality. Any time any of it changes, it has to change *everywhere*. By encapsulating the magic number in an implementation of what the magic number *means* you reduce that coupling and isolate network-specific functionality. Whether or not it's worth it to do so depends in this case depends on info we don't have. – Dave Newton Oct 06 '11 at 16:38
  • Thanks, nice to hear the reassurance. Sometimes I think I'm borderline OCD, lying awake at night worrying about these kinds of things. :) – Sean Oct 06 '11 at 16:40
  • Dave Newton: Interesting. Can you expand on how one could "encapuslate the magic number in an implementation of what the magic number means"? – Sean Oct 06 '11 at 20:33