How bad is it to store class and assembly names in the database?

Question

In brief:

Is it ever excusable to have assembly names and class names stored in the database? Does it break the layers of an application for the data layer to have explicit knowledge of the internals of the business layer?

Full explanation:

I have a boot strapper that runs "jobs" (classes that inherit from a common base) that exist in separate assemblies. The jobs have configuration parameters stored in the database to allow their operation to be altered by means of a GUI.

In order to locate and run a job, the boot strapper has an app.config file that contains the name of the job, and the assembly name and class name that defines it.

I have been asked to move the assembly name and class name into the database so that we can get rid of the app.config file. (Reason given is to keep all configuration in the one place - the database.)

However, the boot strapper is the only code that will run the job and this "configuration" information will never be changed after deployment. I think that putting such information into the database gives the data layer too much information about the layers above, and will get in the way of refactoring and maintenance. However, I know that Windows Workflow Foundation does exactly this, and so perhaps I am wrong to think it is a poor practice?

Edit:

In answer to a question below, the database connection string is stored in a separate config file that is managed by a shared configuration framework. This framework makes it technically possible to remove the app.config file completely.

Answer 1

Where will you store the connection information needed to reach the database?

Answer 2

I think it's perfectly acceptable to store configuration info including assembly/class names in the database.

I wouldn't consider data stored in the database to be part of the data layer.

Answer 3

Nothing wrong with it, especially if you are using it in dynamically loading situations.

The model/data layer doesnt "know" anything really, it's just a repository to hold whatever you want.

Answer 4

To sidestep this a little bit, with an example which justifies your implementation:

When you use an IoC container like Windsor or Unity, you store your assembly/class names in your config file. Again, this is not compiler checked, as you can change this without having to recompile your code. It's similar to storing your mappings in a database, the only thing that changes is the source of your config.

Best thing you can do (and I gather from your question that you do) is to program against abstract base classes or interfaces, so you don't have to rely on reflection to get information about the class you have to run. That way you can essentially create all your logic, and inject your dependency at runtime when you have to by reading your config from the database.

Answer 5

Computers are your slaves, not the other way around and yes the database isn't being burdened with extra technical responsibilities just because its storing a long string for its master rather than a shorter one. This is effectively the argument I made when I proposed the exact same thing for a reporting application in 2002, only to be shot down by the "Java team" (I was working for the accounts department and was in favor of putting fully qualified class names in the DB).

The questions you need to make central should be whether there is outstanding refactoring to be done now and whether the additional changes and refactorings you expect to come later make administering the database a pain. You are right to suppose that having a config file deployed with your binary is a fundamentally better approach to deployment as there is never an issue with keeping the data and binary in synch while different people deploy updates.

Your the developer though, so its your call isn't it? If not, then that's a shame, but make it clear what your view is and try to quantify the costs (with an honest method) and if your way is cheaper you'll probably get your way. However, how much does it cost to argue about it?

PS I'm upvoting the guy who asked where the DB connection string goes!

Answer 6

Sure, I do exactly that for the menus in our application.

When the program loads, it scans the database and loads the menu items by class name that the program can support. If a newer version is needed, a place-holder is shown instead.

Answer 7

I don't see a problem with this, although I have not heard of the database as being that repository.