You Had One Job to Do, Base Business Central Code!
Base Business Central code is poorly written. There! I said it! Out loud! Now, that’s my opinion. And with anything related to development quality, it all depends on the perspective you’re approaching it from. I don’t mean to say Business Central code is buggy or unreadable or to imply that it is a flawed system – far from it. Business Central is guilty of something most applications are guilty of: bad code structure.
Let’s jump in the time machine and go back 50 years to 1972 because these ideas have been around for that long. David Parnas published a paper, “On the Criteria To Be Used in Decomposing Systems into Modules.” In short, the idea was that instead of designing the structure of your system based on a flow chart, it should be separated, in part, by the way, that the code might change.
“Objects with a single responsibility are easier to explain, understand, and implement than the objects that try to do everything. That means it’s easier to create and less costly to maintain and upgrade.”
You’re already bored, aren’t you? Hang in there. Various others introduced topics around this area, like coupling and cohesion, and roughly 25 years later, they were consolidated into what’s known as the Single Responsibility Principle by Robert Martin. This principle states that a module should be responsible to one, and only one, actor. An object should have exactly one reason to change. An actor is essentially a person or a role at a company, like the CFO or a Warehouse Manager.
Why does this matter? Because objects that have a single responsibility are easier to explain, understand, and implement than objects that try to do everything. That means it’s easier to create and less costly to maintain and upgrade. When changes have to be made, there is less risk of introducing new bugs.
Look at the OnDelete trigger of the Customer table in Business Central. A partial snippet is shown below.
You can already see that there is code to handle Service Items and Jobs. More is not shown: Bank Accounts, Campaigns, Item References, and others. That’s five separate modules, potentially five separate actors, that could dictate how this code changes. We want to design our code for high cohesion (things that change for the same reason) and low coupling (things that change for different reasons), not the other way around. Right now, we have high cohesion and high coupling.
Writing Code: Challenging Preconceived Thoughts and Targeting a Quality Solution
You may ask, how would you write this better? To start, we don’t want to decrease cohesion. That means code that does things like deleting related comment lines should probably stay here. We do want to reduce the coupling. That means each of those modules or actors probably becomes its own codeunit with a subscriber to OnBeforeDeleteEvent for the Customer table. This is not to be confused with the event on line 1825 – OnBeforeOnDelete. In a possibly extreme change, again depending on your perspective, each of those codeunits is actually in its own app.
I can hear it now. Five objects? Five apps? That makes my code less readable! What about the performance hit of having so many event subscriptions? But I can’t control the order of execution!
My answer to all of those and more is…Ok. Some I will disagree with, like the readability “issue,” others I can understand, such as performance. There are always trade-offs when emphasizing any one quality characteristic. The important thing is that you’re actively thinking about the quality of your solution, what is important, and challenging preconceived notions about how things should be done. If you want to emphasize structure, one thing to remember is that the reasons for change are people. You don’t want to confuse those people, or yourself, by combining and mixing code that many different people care about for various reasons.
Join ArcherPoint’s Team and Employ Your Developer Skills
ArcherPoint is always looking for talented and dedicated developers that want to take on challenging projects in the Microsoft Dynamics community. We have a roster of Microsoft MVPs at ArcherPoint, and we are always looking for developers and functional consultants.