When is a layer cake healthy?

Every couple of weeks or so, we receive an email or phone call asking a particular question. The question is common enough that I think I should reply to it here, in a public forum, so that I can link to or point to it in future.

The question usually goes like this. (All numbers are made up for this discussion, but they're in the ball-park for those times I've replied. The products are not just limited to the .NET products, by the way, this Q&A applies to our VCL products as well.)

"We have three developers doing UI work. They're the only ones using your UI controls inside the IDE. We also have ten other developers doing other work on the application, and they need to have your controls installed in order to compile it. Do we need an extra ten licenses to your product?"

As posed, the short and indeed only answer to this question is yes. Those other developers do indeed need their own license to our product. If they can't compile the application without having our product installed, they'll need a license otherwise they are in violation of our EULA (End-User License Agreement).

Now, of course, most customers now ask something along these lines:

"That's ridiculous [or some other, er, similar adjectival phrase]. I don't want to buy another 10 licenses just so they can compile! Is there any way around this limitation?"

Depending on the adjectival phrase used, I'll generally launch into my stock answer.

Of course there's a way round this, which in and of itself is not free: divide up the application into layers. As an absolute minimum there should be two layers, although generally people choose three. The user interface (or presentation layer, in the standard architectural parlance) is a totally separate layer (set of assemblies, if you will) from the rest of the application. The other layer is a data access layer, or, if you really want to follow the standard there will be two extra layers: the business layer (containing the business rules and logic) and the data layer (containing the code needed to access and update the persistent data, be it in a file or database.

Dividing up your application like this gives you several major benefits:

• You only have to buy licenses to our products for those developers working on the presentation layer.
• The layers, being separate from each other, only linked up when the application runs, are more easily testable. No longer do you have to test your business logic through the user interface; perhaps the most inefficient way of testing business logic ever devised. It means you don't have to worry about finding a testing application that drives your application through the user interface -- always an expensive proposition. Testing business logic through an interface to that logic is much easier, more thorough, doesn't break when the user interface changes, and can be done unattended.
• You have separate, parallel development projects that can proceed at their own pace. The user interface can be developed independently of the business layer and can use a mocked up implementation to provide data. Since most applications, rightly or wrongly, are judged on their user experience, you can spend more time and effort in prototyping the UI independently of the business logic.

There are of course some caveats:

• The IDE doesn't help you develop these layers in any meaningful way. In fact, the very reason people like IDEs in the first place are for their RAD (Rapid Application Development) abilities and those abilities are most easily expressed by creating an application with everything dumped in one EXE file. It's just so easy to double-click a button and write the business logic there and then in the button click event handler.
• Most developers are used to being able to have everything in one solution and being able to compile and run the whole solution. Layering your application means that ability is lost.
• Layering your application means some more "architectural" work up front. You have to decide on how to do the layering, which pattern (MVC, MVP, etc) or presentation framework to use (for example, CAB), and to enforce its use. There is always the issue of the presentation/business layer interface and who controls it and who is able to make changes to it (which, if you think about it, has the opportunity of really breaking the application big-time).
• You have to consider the functional testing aspects of the application more, that is, running the application as a whole rather than each layer individually.

Of course, there are costs and liabilities associated with whatever course you take. You may decide that the convenience of allowing all developers to recompile all the application all the time far outweighs the cash outlay of extra licenses. Or you may decide the benefits of better testability are a good justification for taking the time and resource to layer an existing application, and get the reduced licensing costs for free, as it were. I'm afraid I can't help you there. But having done this layering exercise in an ASP.NET application (possibly the easiest type of application to do this to), I can vouch for the benefits of the architecture. I also know of several customers who have gone this particular route (and I'm trying to get their thoughts as a case study that we can publish).

(As always with a discussion of what our EULA means or doesn't mean, you should consult proper legal advice if you are in any doubt. I am most assuredly not a lawyer.)

FREE DevExpress Xamarin UI Controls