Resources / App.config或Database哪里是应用程序字符串的最佳位置

Question

全部，

我目前正在查看我正在使用的旧应用程序，它使用了从数据库中的App.config和应用程序配置表中检索应用程序配置设置的混合。

在我正在使用的新软件（旧应用程序的一个端口）中，我有一个静态且很少更改的电子邮件地址列表，这将是检索这些的最佳机制。目前我正在使用资源字符串，因此使用它们是一个简单的My.Resources。但是在App.Config或数据库表中存储信息的好处/缺点是什么。

在什么时候使用资源没有意义？

Answer 1

一切都取决于？ 我的一些经验法则是

进入配置/资源文件

1. 每个用户都是一样的，比如图像目录的路径
2. 数据仅在UI级别需要，并且不会经常更改，例如美国州列表
3. 它可能因服务器而异，例如生产与测试的资源URL

进入数据库

1. 它按用户更改或是用户特定数据
2. 可能需要由您的开发小组以外的人维护
3. 它将在UI层之外使用
4. 会定期更新

你做过什么

请勿将代码绑定到您的代码中，我不在乎您是多么积极，因为错误报告通知电子邮件地址不会改变，请不要使用它来代码！或者3年后的2秒配置更改将导致2周的工作，以获得一个过时的遗留垃圾应用程序编译！或者另一个有趣的方法是将xml-schema硬编码到带有

的应用程序中

stringname += "Schema data";
stringname += "Schema data";
stringname += "Schema data";

奇怪的是，同样的人，去看看。

Answer 2

我认为很少更改的设置可以安全地转到app.config。对于团队中的新开发人员来说，这是相当透明的，并且仍然可以在不重新编译的情况下更改设置。

对于经常和经常更改的内容，我会使用数据库，用户配置文件中的设置文件或其他共享位置等。这样可以更轻松地管理配置中的更改。

另一方面，我认为资源文件不是用于存储配置，而是集中在应用程序中的所有硬编码内容（在某些情况下保留翻译等）。如果我继承你的代码，我会非常惊讶。

Answer 3

我要把最低限度放在配置文件中。足以连接到您的数据库或您用作数据源的任何其他内容。这是在某个地方的平面文件中暴露的较少信息。为了存储电子邮件，我会把它放在数据库中。