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

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 acc开发者_如何学编程omplished 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?

---

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.

---

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.

---

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

---

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.

---

I have found that when you first begin to prototype your application it is much faster to use the SQLDataSource object. You can move through as a significant amount of rapid web application design using this method first. As your application begins to grow and reflects the need to move to using a web service for database n-tier connectivity, you can then make your decision at that point. Some of the benefits are producing a functional web app to demonstrate to the clients. Once they agree to the design and approach you can make a decision to perhaps convert the queries into a web service. This is not very difficult as you have already created the queries within the SQLBuilder and you only have to now establish/move these same queries from within a web service, and then call the appropriate web service queries from the UI layer.

This will take time but the prototype web app has already proven the approach is acceptable and has avoided considerable delays messing around we a web service before it is, or perhaps not needed.