Should a internal C# app be compiled with business logic?

Question

[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?

Answer 1

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.

Answer 2

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".

Answer 3

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.

Answer 4

• How long does it take to alter business logic and then recompile?
• How long will it take to alter business logic without recompiling in new version?
• How long will it take to recode it?
• How will this affect maintainence in terms of extra hours spent in the future?
• Are any of the people who need the app unable to alter the business logic because it is in code form?

Answering those 5 questions will yield an answer.

Answer 5

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.

Answer 6

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.

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

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

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.