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

Question

简而言之：

在数据库中存储程序集名称和类名称是否可行？数据层是否可以显式了解业务层的内部结构而破坏应用程序的层次结构？

完整说明：

我有一个引导程序，运行从不同程序集继承的“作业”（类）。作业具有存储在数据库中的配置参数，以通过GUI更改其操作。

为了定位和运行作业，引导程序具有包含作业名称、定义它的程序集名称和类名称的app.config文件。

现在要求将程序集名称和类名称移动到数据库中，以便摆脱app.config文件（给出的原因是将所有配置保留在一个地方-数据库中）。

然而，引导程序是唯一运行作业的代码，这种“配置”信息在部署后永远不会更改。我认为将这样的信息放入数据库会使数据层对上面的层有过多的了解，并且会妨碍重构和维护。但是，我知道Windows Workflow Foundation确实这样做，所以也许我认为这是一个不好的做法是错误的？

编辑：

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

- freshr

Answer 1

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

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

- Joe

---

我犹豫的原因是我认为这会在层之间引入更高程度的耦合。但也许你不同意数据库中存储的数据实际上增加了数据层和业务层之间的耦合程度？我还没有决定！ - freshr

Answer 2

为了避免这种情况，举一个例子来证明你的实现方式：

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

最好的做法（我从您的问题中了解到您正在这样做）是针对抽象基类或接口进行编程，这样您就不必依赖反射来获取有关要运行的类的信息。这样，您可以基本上创建所有逻辑，并在需要时通过从数据库读取配置来注入依赖项。

- Erik van Brakel

Answer 3

如果您在动态加载的情况下使用它，那么它就没有问题。

模型/数据层实际上并不了解任何事情，它只是一个存储所需内容的仓库。

- StingyJack

Answer 4

计算机是你的奴隶，而不是相反，是的，数据库并不会因为为其主人存储长字符串而不是短字符串而承担额外的技术责任。这实际上就是我在2002年为报告应用程序提出完全相同建议时所做的论点，只是被“Java团队”否决了（当时我在财务部门工作，并支持将完全限定类名放入数据库中）。

你需要集中考虑的问题是现在是否有未完成的重构工作，以及你预期的额外更改和重构是否会使管理数据库变得痛苦。你认为将配置文件与二进制文件一起部署是基本上更好的部署方法，这是正确的，因为在不同的人部署更新时，保持数据和二进制文件同步永远不会成为问题。

但是你是开发者，所以这是你的决定，对吧？如果不是，那就很遗憾，但要明确你的观点，并尝试量化成本（采用诚实的方法），如果你的方法更便宜，你可能会得到支持。然而，争论这个问题的代价是多少呢？

顺便说一句，我正在支持问数据库连接字符串放在哪里的那个人！

- Simon Gibbs

Answer 5

当然，我在我们的应用程序中的菜单上正是这样做的。

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

- Grauenwolf

Answer 6

我认为这没有问题，虽然我还没听说过该数据库作为那个代码库。

- David Robbins