Why should I use an N-Tier Approach When using an SqlDatasource is ALOT EASIER ?

Question

When it comes to web development I have always tried to work SMART not HARD. So for along time My Aproach to interacting with databases in my AspNet projects has been this :

1) Create my stored procedures

2) Drag an SQLDatasource control on my aspx page

3) Bind a DataList Control to my SQLDatasource

4) Insert, Update & Delete by using my Datalist or programmatically using built in SQLDatasource methods e.g

MySqlDataSource.InsertParameters["author"].DefaultValue = TextBox1.Text;

MySqlDataSource.Insert();

Recently however I got a relatively easy web project. So I decided to employ a 3-tier Model...But I got exhausted halfway and just didnt seem worth it ! It seemed like I was working too HARD for a project that could have been easily accomplished by a couple of SqlDataSource Controls.

So Why Is the N-Tier Model better than my Approach? Has it anything to do with performance? What are the advantages of the ObjectDataSource control over the SqlDataSource Control?

Answer 1

Here are a couple of reasons for n-tier:

1. n-tier means better scalability. You can add middle tier servers to scale if the database server can't keep up.
2. n-tier allows you to add security outside the database (e.g., enterprise directory servers).
3. n-tier gives you an intermediary that can check for SQL injection, validating and binding variables from the UI.
4. n-tier can mean looser coupling. SqlDataSourceControl means the UI knows all about the database schema. (This one is shaky - if you add a new field, the effect will ripple through the UI no matter what you do.)
5. A middle tier makes it possible for another UI to re-use functionality.

If you're just writing a CRUD web app, with no chance to share and good scalability, your approach might be fine.

Answer 2

There is not really any problem with using the SqlDataSource control if you want to. That being said, there are plenty of valid reasons to use an N-tier system.

1. it tightly couples your presentation layer to your data layer
2. you duplicate a ton of work
3. SqlDataSource queries are often unique

Answer 3

You approached things backwards. The SQLDataSource approach is for small lightweight projects. As soon as you get bigger you'll want to reuse structures and queries between a lot of different pages.

With your approach that means applying the copy/paste design pattern from one page to another just so you can use the same query. Now think what happens when something changes (the DB structure for example) and you have to replicate those changes between 50 pages that all have SQL literals embedded in them - you're in a world of hurt.

Here comes the n-tier model to the rescue - the data access logic should be isolated in its own tier and there should be only one piece of code responsible for a certain business/data logic and if changes need to be done there would be only one piece of code that needs to be changed. The problem with this approach is that it requires more effort up front and the payback is only visible on reasonably big projects.

Answer 4

If you're not building medium or large-sized projects, you've discovered the secret here.

n-tier only helps for bigger applications; below those, it's a practice exercise at best, and a remarkable timesuck regardless.