One of the problems with using .NET, either VB or C#, is that it is too big. I have been playing with this for about 2 years now and I don’t think I will ever get on top of it. There is just too much for one person to learn.

That doesn’t really bother me too much because I really need to concentrate on only those areas which are relevant to to the kind of applications I am writing. But the difficult part is finding out which parts are relevant.

I am planning on having a serious look at Visual Studio 2005, which has been recently released. It is supposed to fix up a number of annoying quirks in the current version, but that will mean learning more new tricks.

However, I found something out this week which solved my problem of the N-Tier Model which I wrote about earlier. In summary, my difficulty was that I wanted as much flexibility as possible in organising the physical layers of an application while maintaining only one logical model.

The problem, as I saw it, was that let’s suppose we are building a 3-tier application. The top layer is the User Interface, the bottom layer is the Database Server, including the data access, and the middle tier is the Business Layer. Depending upon the physical configuration, and some other factors there are a number of ways to configure such a system.

For a stand alone one-user application, everything sits on one PC. A 3-tier physical system would have the logical tiers match the physical, so that the UI sits on each User’s PC, the data layer sits on a data server, and the business layer sits on an application server. In between there are two possibilities. The UI is again on the User’s PCs and the data layer is on a data server. The Business layer can then go either on the data server or on each of the PCs. The final possibility is that one of the User’s PC acts as the server and so the data layer is then on that PC. In this case the Business layer can sit on that PC, or on each User’s PC.

For a small application that is too many possibilities, but they all must be considered.
The 3-Tier physical matching logical model is the easiest. You know where everything is going. Of course, with that arrangement there are serious performance factors to consider. The network is the slowest part of the system, but it would scale well and you can run hundreds of users on such a system. In that case you might want to consider redundancy factors as well, just in case one of the servers or networks failed.

Now to my point. I didn’t want to build a system that would spend all its time creating objects and serializing them to accommodate a network if if wasn’t going to run on such a network.

The good news is that the .NET Framework takes care of all of that. If you build a system which passes serialized objects between two layers which both reside on the same PC then the Framework recognises this, and the serialization does not take place. This, in itself, is a big performance boost. But there is an additional saving in that the objects themselves are not re-created.

As soon as I realised this, all my worries disappeared. The initial code is a little more complex, but the result is a very flexible system, and the big bonus is that because it is compartmentalised, it is very easy to maintain.