2

[背景]

所以，我有一个 C# 应用程序，它是在我来到这里之前编写的。目前，我不在开发组织中，但我是网络营销组织中我的子组的技术负责人。我的职责是流程自动化、最少的桌面支持和定制应用程序，让我们的生活更轻松。

[/背景]

[应用详情]

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

[/应用详情]

内部 C# 应用程序是否应该使用在不重新构建的情况下无法更改的业务逻辑进行编译？

4

6 回答 6

11

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

如果创建输出的规则很简单，每天都在更改并且由用户输入，那么将其编译成二进制文件是完全错误的，投资于 GUI 和一组新的程序员可能会大有裨益。如果规则很复杂，每年更改一次并由管理层强制执行，那么将它们编译到二进制文件中是一种简单且经济高效的方式来维护它们并防止用户摆弄内部结构。

与往常一样，答案必须是“视情况而定”。

于 2009-04-02T16:03:02.453 回答
2

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

于 2009-04-02T16:02:42.877 回答
2
  • 更改业务逻辑然后重新编译需要多长时间？
  • 在不重新编译新版本的情况下更改业务逻辑需要多长时间？
  • 重新编码需要多长时间？
  • 就未来花费的额外时间而言，这将如何影响维护？
  • 是否有任何需要该应用程序的人因为它是代码形式而无法更改业务逻辑？

回答这 5 个问题就会得到答案。

于 2009-04-02T16:04:04.900 回答
1

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

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

于 2009-04-02T16:03:47.523 回答
0

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

于 2009-04-02T16:04:13.807 回答
0

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

首先，永远不要在没有以某种方式记录的情况下将业务规则放入代码中。代码有很多变量，只有其中一些可以安全地更改，同时仍保持正确的行为。我通常在课程开始时放置一个常量来确定可以更改哪些行为，即

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

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

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

如果它不重要并且不太可能经常更改，那么我会将它放在应用程序配置文件（例如 App.config）中并通过强类型配置类访问它，这样您就可以跟踪它的用法以了解何时安全删除或更改。

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

于 2010-01-26T15:31:07.820 回答