default: break;

Layers

As a Software Engineer with a critical eye on software development, I am truly fond of software architectures that are simple, functional & extensible.

I have praised several times the design of a, god forbid, Microsoft product called Reporting Services due to its greatly designed layered architecture, of which you can catch a glimpse here.

The communication protocols that have changed the world we live in today are based on such a layered model and, surprise, most software is.

The most common approach to developing software systems that operate on some sort of data is the seminal three-tier architecture separating Presentation, Business and Data.

Early on in my development career I tried to follow this approach, or some variation of it, and it clearly paid off, so I stuck with it.

Of course, this is only the first step in the natural evolution of a good software designer. Mastering design patterns quickly follows and not soon enough you’re dealing with domain specifications and shared information models.

But i digress. What I mean to stress here is: the implementation technology does not matter. the system design & architecture does. If you haven’t heard this enough, here it is again.

Still, I am surprised to see around me many (commercial) examples of such poorly designed software.

Dumb UI

The Smart UI Anti-Pattern is well described by Evans and is an example of a common problem in software I have come into regular contact with.

Typically, these systems have two layers: the presentation and the data layer, with the business logic spread between the user interface and the database, through the use of some sort of basic Workflows on the UI side and Stored Procedures and Triggers on the DBMS side.

This is even worse then the scenario described by Evans, in which the business logic is all placed in the interface, using the relational database as a shared repository of data.

Also, let me tell you that SQL means “Structured Query Language”. Query as in querying data. SQL is very useful for extracting data, not for applying business logic to it. The next time you use a cursor, you should be using an Entity or a Model of some sorts in your favorite OOP language.

When you have business & domain logic spread throughout both layers, maintenance, flexibility & integration have all gone down the drain. Yet, he still legitimates this approach when certain conditions are in place. I refute them:

• High & Immediate Productivity for Simple Applications. It comes at a cost. 5 years down the road, when you need to integrate your application with another COTS or the likes, it will burn you. Also, simple applications usually turn into complex applications.
• Less capable developers can work this way with little training. Hire capable developers and / or train them.
• Applications are decoupled from each other. Expanding the system with additional, simple behavior can be easy. When you add several simple “things”, then it becomes complex, no?
• 4GL tools work well. No refutation possible. Still, it comes at a cost.
• Easier maintenance. When in contact with several simple UIs that share a common domain model but there is no sign of that model in the code, just OnClicks and RecordSet iterations and Stored Procedure invocations that do not express adequately the logic being applied, how can it be easier?

The disadvantages are huge:

• Integration is difficult except through the database. Use a “Smart UI” when you are “dumb” enough to think that the data in your application won’t be of any use outside of it.
• There is no reuse of behavior, no abstraction. Business rules are duplicated. Bugs! Bugs! Bugs! Oh, my business logic changed and I forgot to make changes to all the Nth places that refer to this work flow.
• Natural limit for rapid prototyping & iterations. Ruby advocates will tell you otherwise :)

This rant is an effort to spread good design practices because the use and abuse of such anti-patterns have become so common that there is a whole business model built around them. It’s called Enterprise Application Integration and it enables you to pay to the consultant what you tried to save by not hiring capable developers or procuring yours COTS adequately when the time was right.