是否应该使用业务逻辑编译内部C＃应用程序？

Question

[背景]

所以，我有一个C＃应用程序是在我到达之前编写的。我此时并不在开发组织中，但我是互联网营销组织中的子组中的技术主管。我的职责是流程自动化，最小的桌面支持以及使我们的生活更轻松的自定义应用程序。

[/背景

[应用详情]

我们有一个应用程序，可以从URL列表中创建自定义数据库文件。它被设计为具有一个输入文件，以及两个使用这些db文件的应用程序的输出文件。两个输出文件之间差异的规则被编译到代码中。

[/ app details]

内部C＃应用程序是否应该使用业务逻辑编译，如果不重新构建它就无法更改？

Answer 1

内部应用程序有一个目标：支持流程。

如果创建输出的规则很简单，每天更改并被用户放下，将其编译成二进制文件是完全错误的，对GUI和一组新程序员的投资可以做得很好。如果规则很复杂，每年更换一次并由管理层强制要求，将它们编译成二进制文件是一种简单，经济有效的方法来维护它们并防止用户摆弄内部构件。

与往常一样，答案必须是“它取决于”。

Answer 2

如果定期更改逻辑，则应避免将其构建到程序中。另一方面，由于它是内部的，我猜测重建应用程序所需的过程很少或根本不存在，所以它可能没什么区别。

Answer 3

• 更改业务逻辑然后重新编译需要多长时间？
• 如果不在新版本中重新编译，更改业务逻辑需要多长时间？
• 重新编码需要多长时间？
• 这将如何影响未来花费的额外时间的维护？
• 是否需要该应用的任何人都无法改变业务逻辑，因为它是代码形式的？

回答这5个问题将得出答案。

Answer 4

如果不需要更改逻辑，那么它可能应该与代码一起编译。

另一方面，如果某些因素可能会改变此业务逻辑的行为，那么您应该提供更改它的方法，例如改变其行为的xml配置文件。

Answer 5

当然，如果您知道该实用程序仅在您的组织内使用，并且出于单一目的，将业务规则与逻辑混合没有任何问题。过度设计（在这种情况下，当代码永远不会被重用时使代码可重用）不会有效地利用资源。

Answer 6

我通常根据变化概率采用多种配置策略。

首先，从不将业务规则放在代码中，而不以某种方式记录它。代码有很多变量，只有一些变量可以安全地更改，同时仍然保持正确的行为。我通常在课程开始时设置一个常量来确定可以改变的行为，即

// Prefer this
const int AllowDownloadAttempts = 2;
if (AttemptDownload() > AllowDownloadAttempts) RegisterAndAllowDownload();

// Over this
if (AttemptDownload() > 2) RegisterAndAllowDownload();

我遵循的基本规则是必须记录[-1,0,1]以外的任何内容。

如果它并不重要且不太可能经常更改，而是将其置于应用程序配置文件（例如App.config）中并通过强类型配置类访问它，以便您可以跟踪其用法以了解何时可以安全地删除或更改。

如果需要经常更改或由业务用户更改，那么我会将其存储在数据库中并提供一个简单的GUI来编辑它，然后在应用程序加载时将其加载到强类型配置类中。