One thing has been bothering me as I read this book, and I'm hoping that someone who knows more about designing n-tier systems can explain this to me.

In the book, there are several instances where they pass a DataSet up out of the data layer, through the business layer, and up to the presentation layer. I can see why this is useful for databinding etc, but doesn't that totally break the concept of layered abstractions? Now, if I make a change to the database schema, the change is not localized to the Data Layer classes...it affects all layers.

Can anyone explain to me the reasoning behind this? It seems like a poor design.

I just finished reading some part of the Chinese version of this book. I don't think the structure of the example system is good either.

But in my opinion, it's good idea to use datasets in biz tier and UI tier, for the benefit of databinding, data version control etc.

For a good designed n-tier system, these datasets must be defined in biz tier, with biz tier's logic. We define these dataset just like we define a struct type, or a class. The data tier's job is to map the data between database and these biz-defined dataset.

Use the .xsd to define your own dataset, then create the class automatically in visual studio.

Biz tier and UI tier should not use any datasets but those being defined this way. So all the dataset returned by data tier should be these biz-defined dataset. Use TableMappings in data tier object to map the raw dataset into biz-defined dataset is quit simple.

How do you think about it?

You're right. The solution I prefer for databinding is to use custom collections, as described in the APress book: Real World ASP.NET Best Practices. By using collections you can control what info is passed between layers and you don't have to pass every field in the DB. The collections are each created by a business object. The business object layer reads from the data layer and creates the desired collections, and they are passed up to the presentation layer.

However, having said that, it's very hard to isolate changes to one layer because many changes will inherantly apply to more than one layer. But it does help with small changes - like if you want to add one field to be used by one functional area, you want to keep that change contained as much as possible.