Go to episode two
Go to episode one
Client / server could have been a much more successful era in software development, if it wasn’t for this copy-and-paste programming, leading to applications that slowly became unmanageable. I have seen this anti-pattern occur in any of the popular client / server technologies. Without exception, whether it was Visual Basic, PowerBuilder or SQL:Windows and even the older web technologies, such as ASP and even early Java applications.
Splashed business logic
We still bare the fruit from the client / server era. Many of the projects we currently undertake are application migration projects, or re-engineering projects. Although tools exist that claim to do fully automated migration of client / server apps, I find that hard to believe. Having done many code reviews on these poorly constructed applications, these all seem to have one thing in common: the business logic is splashed all over the place, and hardly ever consistent.
Single point of truth
And the nasty thing is: we could have prevented most of this problem, if we would have known then what is now much more common, although less widespread as it should be. But I’ll come back to this in later episodes.
We should have introduced a single point of truth in our client / server applications. We should have constructed a domain layer – or business layer – that contains our business rules and validations, as in the figure below. Separating concerns is a popular catch phrase. In this case separating the presentation logic of the user interface from the domain logic in the domain layer.
Now we only have one location of our simple business rule. For now, I’ll leave it in the middle where in the domain the business rule sits. There are a few options. If the customer changes his mind in this situation not much harm is done. We simply modify the one business rule in the domain layer and we’re back on the road. All presentation logic simply refers to this location, so we’re good.
For as long as they both shall live
Of course, this refactoring comes with a couple of consequences. For starters, you could reason about the fact whether a copy of the business logic should also be present in the database underneath. There are a couple of thoughts to consider here:
- How and by whom is the is the database approach. If our application is the only party to talk to the database, and if this situation remains in tact, you’re quite safe, and you could consider not implementing the rules in the database.
- If you’re not sure who else approaches the database, you will need to implement the rules at least in the database too, otherwise there is no way of guaranteeing continuity and consistency.
- If you decide to have the business rules implemented double, make absolutely sure that the two versions of the truth are in sync, and will remain in sync for as long as they both shall live.
This taking into consideration, applications and database should have been much easier to extend and to maintain. Of course, back in the nineties of the previous century, more and more people started to realize this. That’s when multi-layered architectures became in fashion, which they still are.