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

简而言之：

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

完整解释：

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

为了定位和运行作业，引导程序有一个app.config文件，其中包含作业的名称以及定义作业的程序集名称和类名

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

但是，引导程序是运行作业的唯一代码，部署后，此“配置”信息永远不会更改。我认为，将这些信息放入数据库会给数据层提供太多关于上面各层的信息，并且会妨碍重构和维护。但是，我知道Windows工作流基金会确实做到了这一点，所以也许我认为这是一个很差的实践是错误的？ 编辑：

---

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

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

---

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

它没有错，特别是如果你在动态加载的情况下使用它。

---

模型/数据层实际上并不“知道”任何东西，它只是一个存储库，用来存放您想要的任何东西

通过一个证明您的实现正确的示例，稍微回避一下这一点：

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

---

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

计算机是您的从属设备，而不是相反，是的，数据库不会因为为其主数据库存储长字符串而不是短字符串而承担额外的技术责任。这实际上就是我在2002年为一个报表应用程序提出完全相同的建议时提出的论点，结果被“Java团队”否决了（我当时在会计部门工作，赞成在DB中使用完全限定的类名）

您需要关注的问题应该是，现在是否有尚未完成的重构，以及您希望稍后进行的其他更改和重构是否会使数据库管理变得困难。您可以正确地假设，使用二进制文件部署配置文件从根本上说是一种更好的部署方法，因为在不同的人部署更新时，保持数据和二进制文件的同步从来没有问题

你的电话是开发人员的，所以这是你的电话，不是吗？如果没有，那就太遗憾了，但是要明确你的观点，并尝试量化成本（用诚实的方法），如果你的方法更便宜，你可能会得到你的方法。然而，争论到底要花多少钱

---

PS我正在投票给那个问DB连接字符串去哪里的家伙

当然，对于我们应用程序中的菜单，我就是这么做的

---

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

我认为这没有问题，尽管我没有听说数据库是存储库

我对此犹豫不决是因为我认为这会在层之间引入更高程度的耦合。但是，您可能不同意数据库中存储的数据实际上增加了数据层和业务层之间的耦合级别？我还没决定！