[背景]
所以，我有一个 C# 应用程序，它是在我来到这里之前编写的。目前，我不在开发组织中，但我是互联网营销组织中我的子组的技术负责人。我的职责是流程自动化、最少的桌面支持和定制应用程序，让我们的生活更轻松。
[/background]
[应用详情]
我们有一个应用程序可以从 URL 列表创建自定义数据库文件。它被设计为有一个输入文件和两个输出文件，用于使用这些类型的 db 文件的两个应用程序。两个输出文件之间的差异规则被编译到代码中。
[/应用详情]
内部 C# 应用程序是否应该使用未经重新构建就无法更改的业务逻辑进行编译？
【问题讨论】：
标签： c# automation business-logic
内部应用程序只有一个目标：支持流程。
如果创建输出的规则很简单，每天都在更改并且由用户输入，那么将其编译成二进制文件是完全错误的，投资于 GUI 和一组新的程序员可能会大有裨益。如果规则很复杂，每年更改一次并由管理层强制执行，那么将它们编译到二进制文件中是一种简单、经济高效的方式来维护它们并避免用户摆弄内部结构。
与往常一样，答案必须是“视情况而定”。
【讨论】：
如果定期更改逻辑，则应避免将其构建到程序中。另一方面，由于它是内部的，我猜测重建应用程序所需的过程很少或不存在，所以它可能没有太大区别。
【讨论】：
回答这 5 个问题就会得到答案。
【讨论】：
如果不需要更改逻辑，那么是的，它可能应该与代码一起编译。
另一方面，如果某些因素可能会改变此业务逻辑的行为，那么您可能应该提供一种改变它的方法，例如改变其行为的 xml 配置文件。
【讨论】：
当然，如果您知道该实用程序将仅在您的组织内使用并且用于单一目的，那么将您的业务规则与逻辑混合没有任何问题。过度设计（在这种情况下，在代码永远不会被重用的情况下使代码可重用）不会有效地利用资源。
【讨论】：
我通常根据变化的可能性采用多种配置策略。
首先永远不要在没有以某种方式记录的情况下将业务规则放入代码中。代码有很多变量，只有其中一些可以安全地更改，同时仍然保持正确的行为。我通常在类的开头放置一个常量来确定可以更改的行为，即
// Prefer this
const int AllowDownloadAttempts = 2;
if (AttemptDownload() > AllowDownloadAttempts) RegisterAndAllowDownload();
// Over this
if (AttemptDownload() > 2) RegisterAndAllowDownload();
我遵循的基本规则是必须记录除 [-1, 0, 1] 以外的任何内容。
如果它不重要且不太可能经常更改，那么我会将其放在应用程序配置文件（例如 App.config）中并通过强类型配置类访问它，这样您就可以跟踪它的使用情况以了解何时删除或更改它是安全的。
如果需要频繁更改或由业务用户更改，那么我会将其存储在数据库中并提供简单的 GUI 进行编辑，然后在应用程序加载时将其加载到强类型配置类中。
【讨论】：