For the rest of the book, Lhotka describes the CSLA framework; a toolset he developed which is intended to hide many of the implementation details just discussed. While there are situations where his framework has it's uses, Lhtoka describes it as if it were the Swiss-Army knife of business development. Unfortunately, it isn't. What Lhotka has really discovered is a good way to build applications that works for *him*, but he seems determined that *all* developers would be better off if they all worked similarly.

Pro-golfers know that there is no such thing as a perfect swing. Every golfer is different, and the ultimate swing for one is completely different from the ultimate swing for another. Business development is the same. Each project and even each combination of developers will benefit more from coming up with a style that suits thier particular situation best rather than force-fitting a generic solution, such as CSLA, to thier individual effort.

Lhotka is an accomplished developer. Therefore this book would have been better positioned as a career-autobiography. In other words it's central message would have worked as: "I'm a successful person, and here's how I accomplished it". Instead, the message it delivers is "If this framework worked for me, it must work for everyone". Any pro-golfer (or experienced business developer) will tell you that this simply isn't true.

In case you're unaware of it's history, this book is meant to be Lhotka's update of his CSLA framework for .NET. Unfortunately, the fact that it wasn't designed for .NET handicaps it severely. For example, in several places, Lhotka uses "tricks", such as reflection to compensate for what he calls limitations of the .NET framework. In reality, what Lhotka is compensating for in these areas is simple poor design, especially the aforementioned fact that it doesn't really fit with the .NET framework design. This is unfortunate, because what it really shows is that CSLA would benefit more from a complete, ground-up redesign for .NET instead of an ill-conceived retrofit. A much better framework could be developed by embracing certain features of the .NET framework instead of trying to thwart them.

Inexperienced developers will probably pick up some good n-tiered component development practices from this book, but they will probably also pick up some bad ones, and unfortunately, being inexperienced, won't know which is which. Experienced developers will read this book, shrug, and move on to a more insteresting one. Someone from either group who is interested in learning more about n-tier business development would do better to pick up a book on pure theory, or dedicated to solving his or her specific business problem. Unfortunately, since this book tries to be both things, it ends being good at neither.