Tuesday, November 13, 2007
« Upcoming business-focused CSLA .NET webc... | Main | CSLA .NET Status Update - November 2007 »
Primary motivations to move from 2- to 3-tier

I always encourage people to go with 2-tier deployments if possible, because more tiers increases complexity and cost.

But it is important to recognize when the value of 3-tier outweighs that complexity/cost. The primary three motivators are:

  1. Security – using an app server allows you to shift the database credentials from clients to the server, adding security because a would-be hacker (or savvy end-user) would need to hack into the app server to get those credentials.
  2. Network infrastructure limitations – sometimes a 3-tier solution can help offload processing from CPU-bound or memory-bound machines, or it can help minimize network traffic over slow or congested links. Direct database communication is a chatty dialog, and using an app server allows a single blob of data to go across the slow link, and the chatty dialog to occur across a fast link, so 3-tier can result in a net win for performance if the client-to-server link is slow or congested.
  3. Scalability – using an app server provides for database connection pooling. The trick here, is that if you don’t need it, you’ll harm performance by having an app server, so this is only useful if database connections are taxing your database server. Given the state of modern database hardware/software, scalability isn’t a big deal for the vast majority of applications anymore.

The CSLA .NET data portal is of great value here, because it allows you to switch from 2-tier to 3-tier with a configuration change - no code changes required*. You can deploy in the cheaper and simpler 2-tier model to start with, and if one of these motivators later justifies the complexity of moving to 3-tier, you can make that move with relative ease.

* disclaimer: if you plan to make such a move, I strongly suggest testing in 3-tier mode during development. While the data portal makes this 2-tier to 3-tier switch seamless, it only works if the code in the business objects follows all the rules around serialization and layer seperation. Testing in a 3-tier mode helps ensure that none of those rules get accidentally broken during development.

Architecture | CSLA .NET
Tuesday, November 13, 2007 4:37:50 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [5]  |  Related posts:
Silverlight data portal, async calls and 404 errors
CSLA .NET Master Class in November
Overview of CSLA .NET 3.6 for Windows and Silverlight
CSLA .NET 3.6 for Windows and for Silverlight Beta 1 released
CSLA .NET 3.6 (Silverlight and Windows) pre-release (080919)
CSLA .NET 3.6+ in VB - a community effort?

Wednesday, November 14, 2007 8:44:47 AM (Central Standard Time, UTC-06:00)
A few comments:

1. Regarding Point #1, Security: This point makes an assumption is based on the caveat that the database is no longer exposed to the outside world and is only accessible via your application server. If your application is not the only one connecting to that database then you may not have the opportunity to make a switch to 3-tiered as easily as you make it sound.

2. Regarding Point #2, Network infrastructure limitations: Much like programming a user interface for the lowest common denominator (resolution), when developing a network-enabled application where you don't control or knowledge of the connection speed/bandwidth of a user, you have to program for the lowest common denominator (bandwidth). Being that database connections via ADO (or its various flavors) are more heavier in weight than an HTTP connection to a stateless web service, having direct connections to a database from your front-end application tend to be a very poor choice. "Chattiness", in this case, is not a feature of the protocol but a feature of your application's architecture.

3. Regarding Point #3, Scalability: Database Connection Pooling is not a feature of 3-tier applications. Any application that makes use of the same connection string can benefit from connection pooling. If I am using my own credentials, my connection, even in a 2-tiered architecture, is pooled. If I am using anonymous or hard-coded credentials, everybody's connection is pooled. Refresher: Using Connection Pooling with SQL Server:
http://msdn2.microsoft.com/en-us/library/8xx3tyca(VS.80).aspx
Additionally, the advantages of a scalable (meaning scale out), 3-tiered application are only realized if your middle tier is state-less.

I am not ready to drink the "allows you to switch from 2-tier to 3-tier with a configuration change - no code changes required" Kool-Aid. Smells too much like an "IT/Deployment issue ignored" marketing ploy.

JH
Wednesday, November 14, 2007 9:37:49 AM (Central Standard Time, UTC-06:00)
1. For a web app that's true, and is often the case. For a smart client app the database server is often still "accessible" but just moving the credentials off the client is often a big enough gain in security to make it worth having an app server. This is not a black and white issue - there's a lot of variation in solutions based on the threat analysis results for individual organizations/applications.

2. Dismissing 2-tier models as bad is 10-year old thinking. Certainly it was bad a decade ago, but I know of several 2-tier systems supporting hundreds (like 300-400) concurrent users without a problem. Modern hardware/software is up to the task. But if the bandwidth between client and database is limited, 3-tier is often a better choice. It is easier to use an app server than to try and optimize communication patterns using ADO.NET or other direct-to-database technologies.

Yes, services are a viable alternative, but SOA is expensive. SOA might be the right answer, but it must be justified as having more value than n-tier, because it also has higher costs.

3.True, database connection pooling is automatic in most .NET data providers. However, if you have 500 concurrent users on 500 workstations, the connections will be pooled only on each machine, so the database will have at least 500 connetions open. This can be an issue. Using an app server, the 500 users talk to an app server and may only use 50 database connections (honestly, more like 10-20 in my experience). This is what I mean by gaining connection pooling.


Regarding the data portal's transparent 2- to 3-tier switch, I wouldn't take my word for it either. But it is foolish to dismiss really cool technology out of hand as well. Fortunately for both of us, CSLA is free and you can download it and the reference app from www.lhotka.net/cslanet/download.aspx. Then you can give it a try and see that it really does work.

However, it is true that it only works if you buy into the architecture and design patterns behind CSLA. If you don't buy into those concepts you'll implement your objects and/or UI incorrectly and it won't work. That's obviously a very big caveat, but one that applies to almost any cool solution to these complex problems - follow the rules and life is good, buck the rules and you lose the benefits.

This is why testing in 3-tier mode is so important when using the data portal - because that way you catch any rule violations (where the developer did something against the architecture/design patterns set out by CSLA) early and can fix them when it is still reasonable inexpensive.
Rockford Lhotka
Thursday, November 15, 2007 12:11:29 AM (Central Standard Time, UTC-06:00)
I haven't heard of any architecture of monster companies that have to seriously worry about scalability (like google, ebay, flickr, etc.) that has ever been pro-"expose the database and make direct connections because that's a great and scalable idea". Even though you don't want to design for the future, why would you start off by limiting your application's ability for that client to "hit it big" because of a (by the time you actually hit that surprise user explosion) limited initial architecture?

Don't get me wrong, I understand that you can't afford for the counter point I have raised to bear much weight and this is a poor forum for me to discuss this because of your investment in CSLA. I just felt that some of the points you were making in your initial post were misleading, thus I felt the need to try and shed a different light.
JH
Thursday, November 15, 2007 7:36:36 PM (Central Standard Time, UTC-06:00)
I love this post...I mean it's so common sense and the people I work with who have these 7+ tier systems and wonder why everything is so hard to do and build on top of scoff at this line of thinking.

[quote]
However, it is true that it only works if you buy into the architecture and design patterns behind CSLA. If you don't buy into those concepts you'll implement your objects and/or UI incorrectly and it won't work. That's obviously a very big caveat, but one that applies to almost any cool solution to these complex problems - follow the rules and life is good, buck the rules and you lose the benefits.
[/quote]

And that is exactly it. But honestly, I don't see how anyone can not buy into CSLA - it's like one of those light bulbs that goes off...kind of like when you first realize that writing unit test isn't a waste of time or that requirements are the most important part about software.
Brian Johnston
Thursday, January 03, 2008 2:51:41 PM (Central Standard Time, UTC-06:00)
I support Rockford Lhotka justification on Application Server development.
If security and scalability is the issue then application server solution is what the needed. I worked in finacial organisations (banks and holdings) they all use application servers in their business. Client applications are smart clients.
But all application servers that i saw didnt included server side data access code in client assemblies.

But as i wrote previously in CSLA it can be eliminated from client assemblies with ?#define conditional compilation, so on client that server side code didnt compile in the assembly.
maxim
Comments are closed.