Wednesday, May 28, 2008

Demystifying the n-Tier Architecture(Part 1)

 

When it comes to good application design, separating the business logic from the UI is essential. It is true, splitting your tiers makes your application more testable, maintainable, and extensible.

A number of developers have come up to me to ask how to pass Entities (as in the Entities Framework) over web services, I began realizing that there are common misconceptions on what nTier ***really *** means for .NET applications and services...

This post is a part of a series that I am putting together to make Architects and developers understands the choices they make while realizing their designs.

The issue can be boiled down to misunderstanding the terminology of ported over from the Visual Basic 6 days and the good ol' days of ActiveX and DCOM where we have logical and physical definitions began to blur.

In the old days of Visual Basic 6 when we talked about good architecture, we considered packaging classes in a class lib, abstracting, and separating the UI from the business logic to be the good thing (and it sure was).   Inadvertently we have created a ActiveX library when all we wanted was to create a reusable components that could be separate but still part of the project, we now call them namespaces. The thing that made maters confusing is the fact that we could now take the same ActiveX and register it as a DCOM component, blurring the difference between between the logical design model and the physical deployment.

Unlike with the classics, ASP and VB6,  .NET brought the power back to the developers who are now able to virtually anything, anywhere in the code.  Which turned out to be good and bad (depending if you are wiring code, or fixing someone else's bugs).   Strongly-Typed DataSets, namespaces and assemblies, and a variety of options to from Web Services, to Remoting,  to EnterpriseServices became available to developers to realize their designs.  Understandably there is confusion.

There is a fundamental difference between the logical design, service orientation and physical deployment.

In the next few posts I will attempt to demystify what are the patterns that will benefit your application

3 comments:

Justin said...

I am trying to persuade our development team to avoid a "physical" n-Tier platform mainly due to the over complexity and cost of development. However, the applications are N-Layered giving us the flexibility down the road to move the apps towards different physical servers if needed. Rockford Lhotka explained really well here some of my philosophy. This is in regards to web applications and I understand Windows apps would be handled a little different. In regards to scalability, you can always farm your web servers which have built in db pooling. The security argument I am having trouble articulating to the group.

Could you elaborate on this point and how they might out weigh N-Tier?

Max Zilberman said...

Justin,

Fantastic question....

It is hard to understand the internals of your system as they were not described, but I will attempt to provide some examples.

If you look at the system, the slowest point within the server is disk IO, then followed by the Network IO.

There are many parts to the nTier application, and part of the it is UI, more precisely application validation, some of the validation can be done by merely looking at the values being provided. Like Integer, string, string format, etc. Now for a moment imagine that you have a complete separation of the business and presentation logic via a total physical separation (multi-server environment). Every call to validation would occur over the network.

I truly belive that is an unnessary overhead to the physical n-Tier separation. Network communication by its virtue is non-optimal when compared to straight Disk I/O. The argument is even greater when you have RAID or SAN storage.

I am very familiar with the approach Rockford has taken. Some things I agree with, others I do not.

Another point is, if you are adding a server to your application configuration, why not another web-server? I would only do the physical separation of the tiers if the service being called is external to your "Managed Domain" (meaning you do not own it, or it is a separate application, or it is just not your service).

The Security is another interesting point. The identity needs to be shuttled from one server and payload encrypted and decrypted. Nothing is free, thus the CPU and lateness overhead is always there.

Let me know that helped?

Max

Justin said...

That helped a bunch and it was much appreciated! Thanks!!