在数据库中存储类和程序集名称有多糟糕？

Question

简而言之：

将程序集名称和类名存储在数据库中是否可行？它是否会破坏数据层应用程序的层，以明确了解业务层的内部结构？

完整说明：

我有一个引导strapper，它运行在单独程序集中的“jobs”（继承自公共库的类）。作业具有存储在数据库中的配置参数，以允许通过GUI更改其操作。

为了找到并运行作业，引导过滤器有一个app.config文件，其中包含作业的名称，以及定义它的程序集名称和类名。

我被要求将程序集名称和类名移动到数据库中，以便我们可以删除app.config文件。 （给出的理由是将所有配置保存在一个地方 - 数据库。）

但是，引导过滤器是运行作业的唯一代码，部署后永远不会更改此“配置”信息。我认为将这些信息放入数据库会为数据层提供有关上述层的过多信息，并会妨碍重构和维护。但是，我知道Windows Workflow Foundation就是这样做的，所以也许我认为这是一种糟糕的做法我错了？

修改

在回答下面的问题时，数据库连接字符串存储在由共享配置框架管理的单独配置文件中。此框架使技术上可以完全删除app.config文件。

Answer 1

我认为将配置信息（包括程序集/类名）存储在数据库中是完全可以接受的。

我不认为存储在数据库中的数据是数据层的一部分。

Answer 2

没有任何问题，尤其是在动态加载情况下使用它时。

模型/数据层并不真正“知道”任何东西，它只是一个存储库来容纳你想要的任何东西。

Answer 3

稍微回避这个问题，举例说明你的实施是正确的：

当您使用像Windsor或Unity这样的IoC容器时，您将程序集/类名存储在配置文件中。同样，这不是编译器检查，因为您可以更改它而无需重新编译代码。它类似于将映射存储在数据库中，唯一改变的是配置源。

你可以做的最好的事情（我从你提出的问题中收集）是针对抽象基类或接口编程，因此你不必依赖反射来获取有关你必须运行的类的信息。这样你就可以创建所有的逻辑，并在必要时通过从数据库中读取配置来在运行时注入依赖。

Answer 4

计算机是你的奴隶，而不是相反的方式，是的，数据库不会承担额外的技术责任，因为它为主人存储了一个长字符串而不是较短的字符串。这实际上是我在2002年为报告应用程序提出完全相同的事情时所做的论证，只是被“Java团队”击落（我当时正在为会计部门工作，并赞成放置完全合格的类名在DB）。

您需要考虑的问题应该是现在是否有未完成的重构，以及您希望以后进行的其他更改和重构是否会使管理数据库变得痛苦。您可以认为，使用二进制文件部署配置文件是一种从根本上说更好的部署方法，因为在不同的人部署更新时，保持数据和二进制文件保持同步永远不会出现问题。

你的开发者，所以你的电话不是吗？如果不是，那就太遗憾了，但要清楚你的观点是什么，并尝试量化成本（用诚实的方法），如果你的方式更便宜，你可能会得到你的方式。但是，争论它需要花多少钱？

PS我正在讨论那个问DB连接字符串在哪里的人！

Answer 5

当然，我正是为我们申请中的菜单做的。

当程序加载时，它会扫描数据库并按程序可以支持的类名加载菜单项。如果需要更新版本，则会显示占位符。

Answer 6

我没有看到这个问题，虽然我没有听说过数据库是该存储库。