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