When is a layer cake healthy?

ctodx
04 December 2007

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.)

8 comment(s)
Nate Laff
Nate Laff

Seems reasonable to me. Luckly for me DX lets me use my license on my desktop AND laptop and whatever else I happen to use. Since i'm the only developer it works out well for me.

But one non-visual component I use is a per machine license (dumb) but because of this I just have that  code in it's own assembly (plugin) and I don't have to mess with it on my other machine. It's completely independent.

I think DX is pretty liberal in comparison to other vendors out there and think that it's perfectly reasonable to have everyone that needs it to compile needs their own license.

4 December, 2007
Julian Bucknall (DevExpress)
Julian Bucknall (DevExpress)

What follows has to be the most inapplicable comment I've received yet. It's in reply to this post (URLs removed):

---

When deciding on what cake recipe you would like to create you must keep in mind that there are two types of Cake  – butter and foam. Butter cakes are made with butter or shortening and foam cakes are made with eggs or egg whites. These two categories are just the general, umbrella, or catch-all terms. There are actually dozens or even hundreds of variations on cakes that you can learn about and enjoy.

---

OK, all right then.

Cheers, Julian

5 December, 2007
Gary Gibbons
Gary Gibbons

EH? Hope that batch wasn't from my cook book...

5 December, 2007
drew..
drew..

At the risk of rehashing, and a little off-topic..  and quoting: "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)"

..i wish this was thrown onto the table at the early round-table sessions for xaf.. ☻

5 December, 2007
Anonymous
John Emery

Great post.  The bottom line benefits are tremendous.  One of the problems of moving from the non layered to layered implementation that I have observed is that sometimes, developers fail to recognize that a tangible item exists between the layers.  It is called an interface .  In Win32, we called it the API.  In DOS, we called them 'hand shaking' files.  Failure to identify the interface results in code thrashing and design/team conflicts.  I have found that teams that implement 'cooperation' process rules for maintaining the interface are successful in their move.  Process rules like TTD, design documentation, designated administrator, and team communication is a must.  (But if you are 'the team', use the teddy bear principle in programming)

7 December, 2007
Anonymous
jgv

I generally never comment blogs but that one is so funny that i can't resist, especially the last sentence.

I will comment it as I read it (and english is not my mother language):

Hey guys, I'm the boss of the company, but I'm not really sure of what we put in the eula - or at least I don't want to explain you - so take your time, consult a layer, and well, do your best.

Well, it is my joke but:

 - the only one that will check the eula, in your case, are the developers

 - they don't read it because when they try to read it - they don't understand it (and I had try, believe me, even in my own language, I don't understand them)

 - may be something should be made to improve this (why not a developer eula, you know, the one someone who's not a layer can read - and - understand, so I propose to write a normal text that explain what the eula means and to keep the eula for formal terms).

 - they will certainly not consult a layer for that.

Now, lets talk about technic. Beside the fact your technical proposal is perfect, may be you forget that, at one time or another, the n-tier guy will have to compile the whole application, just to see if it doesn't break the whole. May be his company put in place a daily build (what the name of the 'entity' do I have to send to you ? the computer name ? - no sorry I didn't notice that the eula is reserved to "individual") and so on..

and why this editor is so small ?

Anyway, thanks for the blog :)

13 December, 2007
Anonymous
ctodx

I thought I would just point out a few of my posts from the past -- raising them into your consciousness

18 June, 2008
Chris Lively
Chris Lively

One particular problem here is the focus on the individual developer at the expense of both the Team and publishing capabilities.

By using this licensing model you are in effect forcing each company to purchase a site license; you're just not calling it that.  Which is a bit misleading.

Further, it introduces complexities in automated builds and deployments.  I would dare say that most companies have policies which restrict what can be installed (GAC'd) on a server.  Also, due to the tremendous number of versions you publish, it is quite easy to break an existing production application when deploying a different application.

Each time we decide to upgrade to the latest DevEx controls we have to modify ALL of the project references to remove links to the GAC and instead reference a libraries folder.  If a team member fails to do this, the result is bad builds and non-working projects.  If we don't do this, automated deploys from our build server will fail.

Granted, this is in part do to limitations built in to the VS IDE; namely that GAC'd assemblies are not copied to the output folder during the build.  However, because you are hooked in to that process, usage of DevEx highlights the problem.

Perhaps if you are getting so much email concerning this issue, you might consider revisiting your decisions.  

16 June, 2009

Please login or register to post comments.