简而言之：
将程序集名称和类名称存储在数据库中是否可以原谅？数据层明确了解业务层的内部结构是否会打破应用程序的层级？
完整解释：
我有一个启动捆绑程序，它运行存在于单独程序集中的“作业”（从公共基础继承的类）。这些作业的配置参数存储在数据库中，以便可以通过 GUI 来更改其操作。
为了定位并运行作业，引导捆绑程序有一个 app.config 文件，其中包含作业的名称以及定义它的程序集名称和类名称。
我被要求将程序集名称和类名称移动到数据库中，以便我们可以摆脱 app.config 文件。 （给出的原因是将所有配置保留在一个地方 - 数据库。）
但是，引导捆绑程序是唯一运行该作业的代码，并且此“配置”信息在部署后永远不会更改。我认为将这些信息放入数据库会给数据层提供太多关于上面各层的信息，并且会妨碍重构和维护。但是，我知道 Windows Workflow Foundation 正是这样做的，所以也许我错误地认为这是一个糟糕的做法？
编辑：
回答下面的问题，数据库连接字符串存储在由共享配置框架管理的单独配置文件中。这个框架使得从技术上来说完全删除app.config文件成为可能。
我认为在数据库中存储包括程序集/类名称的配置信息是完全可以接受的。
我不认为存储在数据库中的数据是数据层的一部分。
为了稍微回避这个问题，用一个例子来证明你的实现是合理的：
当您使用像 Windsor 或 Unity 这样的 IoC 容器时，您可以将程序集/类名称存储在配置文件中。同样，这不是编译器检查的，因为您可以更改它而无需重新编译代码。这类似于将映射存储在数据库中，唯一改变的是配置的来源。
您可以做的最好的事情（我从您的问题中了解到您所做的）是针对抽象基类或接口进行编程，因此您不必依赖反射来获取有关您必须运行的类的信息。这样，您基本上可以创建所有逻辑，并在需要时通过从数据库读取配置来在运行时注入依赖项。
计算机是你的奴隶，而不是相反，是的，数据库不会仅仅因为它为其主人存储一个长字符串而不是较短的字符串而承担额外的技术责任。这实际上是我在 2002 年为报告应用程序提出完全相同的建议时提出的论点，但被“Java 团队”否决了（我当时在会计部门工作，并且赞成使用完全限定的类名）在数据库中）。
您需要关注的问题应该是现在是否需要进行突出的重构，以及您预计稍后进行的额外更改和重构是否会使数据库管理变得痛苦。您正确地认为，使用二进制文件部署配置文件从根本上来说是一种更好的部署方法，因为在不同的人部署更新时保持数据和二进制文件同步永远不会出现问题。
虽然你是开发人员，所以这是你的决定，不是吗？如果没有，那就太可惜了，但要明确你的观点，并尝试量化成本（用诚实的方法），如果你的方法更便宜，你可能会如愿以偿。然而，争论要花多少钱？
PS 我支持那个询问数据库连接字符串去哪里的人！
它没有任何问题，特别是当您在动态加载的情况下使用它时。
模型/数据层实际上并不“知道”任何东西，它只是一个保存你想要的任何内容的存储库。
当然，我对应用程序中的菜单正是这样做的。
程序加载时，它会扫描数据库并按程序可以支持的类名加载菜单项。如果需要更新版本，则会显示占位符。
我不认为这有什么问题，尽管我还没有听说过该数据库是该存储库。