when to introduce an application services tier in an n-tier application

Question

I am developing a web based application whose primary objective is to fetch data from the database, display it on the UI, take in user inputs and write them back to the database. The application is not going to be doing any industrial strength algorithm crunching, but will be receiving a very high number of hits at peak times (described below) which will be changing thru the day.

The layers are your typical Presentation, Business, Data. The data layer is taken care of by the database server. The business layer will contain the DAL component to access the database server over tcp. The choices I have to separate these layers into tiers are:

1. The presentation and business layers can be either kept on the same tier.
2. The presentation layer on a separate tier by itself and the business layer on a separate tier by itself.

In the case of choice 2, the business layer will be accessed by the presentation layer using a WCF service either over http or tcp.

I don't see any heavy processing being done on the Business layer, so I am leaning towards option 1 above. I also feel for the same reason, adding a new tier will only introduce the network latency. However, in terms of scalability in case I need to scale up or scale out, which is a better way to go? This application will need to be able to support up to 6 million users an hour. There will be a reasonable amount of data in each user session, storing user's preferences and other details. I will be using page level caching as well.

Answer 1

I would agree with your initial assessment. It probably doesn't make much sense to add an additional network hop into the processing of your system. The reason people separate tiers physically is for reuse across applications. That is you have multiple applications calling the same services to perform a part of their work. As you mentioned, there's not a lot of built in logic the business layer provides; and so far there is only one application using it.

It's good that you have separated the tiers logically but a physical separation at this time might be overkill.

Update to address scalability concerns

I would still argue that keeping the BLL on the same physical tier as the presentation layer is the best approach for now. You can scale out by adding more presentation/bll nodes (already addressed if you're using a fat client deployment, simple enough to do with a web application). Also if you find that the database is becoming the bottleneck, most databases support clustering/sharding and other neat tricks to scale out. Only after I've gone down both of these paths (and of course adding in distributed caching), would I look at adding another physical tier.

Before you can go there however, I'd start looking at making a more "hearty" Business Layer than a simple facade to the Data Access Layer. The first step is to consider using a powerful O/RM that does the data mapping for you. Then consider making your business objects more intelligent. There are reams of paper written on Domain Driven Design (the book is a great place to start). Going through the steps of domain modeling, defining bounded contexts, and finding aggregate roots will help you produce an architecture that has natural seams. This will help split your application into self-contained services that can scale independently as needed.

Answer 2

I am assuming that you are using the term "tier" to mean a physical server. If you do not need to distribute your business and presentation layer I would definitely avoid it. Sending objects over the wire is expensive and prone to issues that if can be avoided should. But you should design your architecture in a way that makes it easy to add more tiers as the system evolves and design considerations warrant distribution. I usually develop an application service layer as a class library/assembly that would have the same interface that your WCF service would have. This is what the presentation layer interfaces with or any other external systems. If the business and presentation layers do not need to be distributed then the presentation layer references the class library directly. If they do need to be distributed then your WCF service is just a thin wrapper around service layer class library that provides the ability to access the service remotely.

Answer 3

Keeping one eye on the future is usually a good thing, but introducing a Service layer, or anything really, when one is not needed may well just be a waste of time now, and slow down your system.

Splitting your system correctly into logical layers is deinitely a good thing and will allow you to extend your system at a later date. Reducing the coupling will make it easier to do this in the future.

As it happens I worked on a large system a couple of years ago which was a website -> service layer -> everything else.

The Service layer was introduced because all the senior architects/managers fell in love with SOA, so our system HAD to become service oriented. "other systems will use our websites middle tier functionality" was the cry.

That decision alone cost the project a year in delays.