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.
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.