C# business logic is applied brain damage

Business logic requirements will change. Hence, applying BL in a programming language requiring recompilation, re-deployment, re-testing, etc - Is the equivalent of attempting to create an airplane out of bricks and mortar. However, don't believe me, let's look at the solutions in a similar type of scenario; Game programming.

All successful games, starting from Wolfenstein and Doom, had scripting languages and dynamic file formats for loading levels. This allowed the creator to use the same "engine" to create multiple games, and/or levels, and apply new scripts for how the NPC characters in the game evolved and behaved. The dynamic parts of a computer game, is the equivalent of Business Logic for an app. Hence, having access to some sort of "dynamic scripting language" to replace your existing business logic, allows you to completely change the nature of your app, yet still use the same core (statically compiled) building blocks. In a computer game, this core is arguably stuff such as the polygon rendering engine, the physics engine, the sound and speech engine - And this stuff should be built in an extremely fast compiled programming language. In an enterprise application, this is stuff such as sending emails, creating database records, authentication and authorisation, etc - And this should also be created in a compiled language.

Creating building blocks in C# for your application, solving the "generic problems", is perfectly fine - But adding stuff such as the following hardcoded, and compiled into your C# code, is arguably pure madness!

x

bool IsCustomer(int id)

{

  using (var context = new DbContext())

  {

    return Users.Any(x => x.IsCustomer && x.Id == id);

  }

}

The reason is that the definition of a customer might change over time, and as it does, the entire application needs to be recompiled, redeployed, and regression tests needs to be applied, towards the entire application.

If you have the ability to dynamic "script" things such as the above instead, you can edit a single "script file", completely modifying the definition of a customer, without recompilation/redeployments/etc. To illustrate the problem, imagine that you need to re-arrange/refactor your database tables, and instead of having a boolean field in your Users table, you create a UserType table, which contains a link between users and "user types". In a scripting language, changing the definition of what constitutes a "customer" is a simple Notepad operation. In a statically compiled programming language, it's the larger parts of an entire 2 weeks long sprint operation.

Solution

I will actually not give you the solution. And my reasons are because I have been accused of marketing my own frameworks and tools here at DZone - Hence, in the interest of keeping this article neutral, and impossible to "attack" in any ways, I will stop here. However, "the truth is out there dude!"