内部 C# 应用程序是否应该使用业务逻辑进行编译？
[背景]
所以，我有一个在我到达这里之前编写的 C# 应用程序。 目前，我不在开发组织中，但我是互联网营销组织内我的子组的技术主管。 我的职责是流程自动化、最少的桌面支持和定制应用程序，让我们的生活更轻松。
[/background]
[应用详细信息]
我们有一个应用可以根据 URL 列表创建自定义数据库文件。 它被设计为具有一个输入文件和两个输出文件，供使用此类数据库文件的两个应用程序使用。 两个输出文件之间的差异规则被编译到代码中。
[/应用详细信息]
内部 C# 应用是否应该使用不重新构建就无法更改的业务逻辑进行编译？
[background]
So, I've got a C# application that was written before I got here. I'm not in the dev org, at this time, but I am the tech lead in my sub-group within the internet marketing org. My responsibility is process automation, minimal desktop support, and custom apps that make our lives easier.
[/background]
[app details]
We've got an app that creates a custom database file from a list of URLs. It was designed to have one input file, and two output files for the two applications that use these sort of db files. The rule for the difference between the two output files is compiled into the code.
[/app details]
Should an internal C# app be compiled with business logic that can't be changed without it being re-built?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
内部应用程序有一个目标：支持流程。
如果创建输出的规则很简单，每天都在变化，并且由用户编写，那么将其编译成二进制文件是完全错误的，投资 GUI 和一组新的程序员可能会带来很多好处。 如果规则很复杂，每年更改一次并且由管理层强制执行，那么将它们编译成二进制文件是维护它们并防止用户摆弄内部结构的一种简单且经济高效的方法。
与往常一样，答案必须是“视情况而定”。
Internal applications have one goal: support the process.
If the rules for creating the output are simple, change every day and are put down by a user, compiling it into the binary is totally wrong and an investment into a GUI and a new set of programmers could do much good. If the rules are complex, change once a year and are mandated by the management, having them compiled into the binary is a simple, cost-effective way to maintain them and keep users from fiddling with the internals.
As always, the answer has to be "it depends".
如果逻辑定期更改，则应避免将其构建到程序中。 另一方面，由于它是内部的，我猜测重建应用程序所需的过程很少或不存在，因此它可能不会产生太大的影响。
If the logic is changed on a regular basis, you should avoid building it into the program. On the other hand, since it is internal, I'm guessing that the process required to rebuild the app is minimal or non-existent, so it may not make much of a difference.
回答这 5 个问题就会得到答案。
Answering those 5 questions will yield an answer.
如果不需要更改逻辑，那么它可能应该与代码一起编译。
另一方面，如果某些因素可能会更改此业务逻辑的行为，那么您可能应该提供一种更改它的方法，例如更改其行为的 xml 配置文件。
If the logic does not need to be changed then yes it should probably be compiled along with the code.
On the other hand if there are certain factors that could change the behavior of this business logic then you should probably provide a mean of changing it such as xml configuration files that alter its behavior.
当然，如果您知道该实用程序仅在您的组织内使用并且用于单一目的，那么将业务规则与逻辑混合在一起并没有什么问题。 过度设计（在这种情况下，当代码永远不会被重用时使其可重用）不会是资源的有效利用。
Sure, if you know that the utility will only be used within your organization and for a single purpose there is nothing wrong with mixing your business rules with the logic. Over-designing (in this case making code reusable when it will never be reused) would not be an efficient use of resources.
我通常根据变化的概率采用多种配置策略。
首先，永远不要将业务规则放入代码中而不以某种方式记录下来。 代码有很多变量，只有其中一些可以安全地更改，同时仍然保持正确的行为。 我通常在课程开始时放置一个常量来标识可以更改哪些行为，即
我遵循的基本规则是必须记录除 [-1, 0, 1] 之外的任何内容。
如果它不重要并且不太可能经常更改，那么我会将其放置在应用程序配置文件（例如 App.config）中并通过强类型配置类访问它，以便您可以跟踪它的用法以了解何时可以安全地使用它。删除或更改。
如果它需要频繁更改或由业务用户更改，那么我会将其存储在数据库中并提供一个简单的 GUI 来编辑它，然后在应用程序加载时将其加载到强类型配置类中。
I usually employ multiple configuration strategies based on probability of change.
First of all never put business rules in code without documenting it in some-way. Code has a lot of variables and only some of them can be changed safely while still maintaining the correct behaviour. I Normally put a constant at the start of class to identify what behaviour can be changed, i.e.
A basic rule I follow is anything other than [-1, 0, 1] must be documented.
If it's not critical and not likely to change often than I would place it in the applications configuration file (e.g. App.config) and access it via a strongly-typed configuration class so you can keep track of its usages to know when its safe to remove or change.
If it needs to be changed frequently or changed by business users then I would store it in a database and provide a simple GUI to edit it then load it into a strongly-typed configuration class when the application loads.