11 of 11 people found the following review helpful:
4.0 out of 5 stars
Substantive discussion of application architecture that puts .Net technologies into perspective, December 27, 2008
This review is from: Expert C# 2008 Business Objects (Paperback)
Since the publication of his Business Object Development Framework CSLA.Net in 2001, the author has been evolving the framework to keep it up to date with new releases of .Net. In this book, he revisits the design philosophies that guide the development of the CSLA.Net framework, and discusses with lots of code samples the changes and/or additions he has had to undertake to incorporate new feature offerings in .Net 3.5 SP1 and make the framework operate seamlessly with .Net technologies mature and newer. For example, because data binding in WinForms, WebForms, and Windows Presentation Foundation works differently in .Net behind the scenes, the author describes how he dealt with such complexities to hide them from users of his framework so that all users have to do to make CSLA.Net work with any of the three UI Technologies is to provide appropriate configuration settings. This is quite an accomplishment and there are many other places in the book where one can glean other thoughtful design techniques such that whether you agree or disagree with the views expressed in this book, you could still acquire a lot of design ideas and deeper knowledge of .Net itself. To be sure, the framework has a steeper than average learning curve, but whether you decide to use the framework or not, time spent studying it will pay off in many ways!!
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
8 of 8 people found the following review helpful:
5.0 out of 5 stars
An Excellent Book and Framework, February 22, 2009
This review is from: Expert C# 2008 Business Objects (Paperback)
If you are reading these reviews and are dissuaded from purchasing this book based on some 1-star reviews, understand the reviewers are judging the book on the basis of object philosophy rather than the pure educational value. CSLA encourages a style of objects that are more "pure" and encapsulated than others, and not everyone is comfortable with that. That's fine, but realize this book offers more than simply discussing CSLA. It includes excellent information around core .NET technologies such as ADO.NET, ASP.NET, WCF, WPF, and Linq. It will also help guide thinking around architectural decisions, regardless of framework choice.
For Example:
* Chapter 3 contains some excellent discussion around Object design and how it differs from database design
* Chapter 20 discusses some of the tough decisions that need to be made around delivering ASP.NET applications
* Chapter 21 will help you make distinctions between an SOA approach vs. Client/Server approach
Lhotka writes in a very clear manner, always offering counter-examples to his choices, and carefully weighs the pros and cons of each. In the end, architectural decisions must be weighed against a value system, and everyone operates from a different set of values.
The Framework: My experience with CSLA has been nothing but positive, but I tend to agree with the its underlying philosophy. It handles all the things that I'd rather not deal with (plumbing for data-binding, rules, validation, distribution, security etc), so I can focus my energy on supporting the use cases and business logic.
Dependency Injection: May folks quickly dismiss the framework as being "not TDD friendly" and "not IoC friendly." I contend that this has more to do with a failure of imagination rather than failure of the framework. Most IoC containers support the "service locator" pattern to inject objects into to classes whose constuction process is outside the control of the developer. Some folks favor "setter injection", but I believe having to use a service locator pattern for DI is a small price to pay to preserve encapsulation and maintain the sanctity of the object API. For those who simply cant get past that, CSLA 3.6 offers mechanisms for users to control construction so dependencies can be injected in alternative ways to the service locator.
Automated Testing: I'm a big believer in automated testing, but our automated tests against CSLA-based objects tend to be integration tests where we run against a live database. We also build smaller objects that contain complex logic and do not require data access to work. These are tested with automated unit tests. Objects such as these are injected into and are consumed by larger CSLA objects. Not everyone will agree this approach, but it has served us well.
SUMMARY: CSLA is not for everyone. If you struggle with an object-mindset, and tend to think of applications in a more data-centric way, you will question the value of the framework and will be better off with other alternatives. I've seen a couple situations where individuals built CSLA-based object models without making any effort to understand the use cases they would ultimately support. Needless to say, the results were not impressive. CSLA will gain you very little if this is how you intend to use it. I suspect it is efforts such as these that tend to tarnish the framework's reputation.
On the other hand, if you think of objects as a means to supporting use cases, and build models accordingly, you will embrace CSLA and end up with very maintainable applications as a result.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
6 of 6 people found the following review helpful:
3.0 out of 5 stars
A mixed bag, June 22, 2011
This review is from: Expert C# 2008 Business Objects (Paperback)
There's a lot to like about this book and Rocky clearly knows his stuff. If nothing else, reading this book will help you clarify your own views about architectural decisions. In addition, there are many technical insights that are relevant whether or not you agree with CSLA. My biggest problem with this book has more to do with the overall philosophical leanings of the author. Rocky notes on page 4 that: "n-tier architectures only simplify the process for large applications or complex environments." This is quite correct, and any developer who has been doing this long enough has surely seen many situations where n-tiers architectures were used where it made absolutely no sense and led to unnecessary complexity and bloat. Rocky goes on to say: "If you find yourself on the edge of choosing an n-tier solution, it's typically best to go with it." I couldn't disagree more! When in doubt, use simple architectures. You can always increase the complexity as the need arises. OO apologists will scoff at this notion, but it is way easier to scale complexity up than it is to scale it down (I mean, imagine trying to simplify/refactor a fully implemented CSLA solution; I've been there, done that, and it's not pretty).
One other primary point in support of the CSLA approach is the idea of "smart" data and encapsulation. This point has some merit to be sure, but I question the cost/benefit trade-offs here.
Ultimately, Rocky is a strong proponent of OOP and that's fine. But if you've written OO code for any length of time, you probably realize that the promises of OO never materialized compared to procedural, data-centric programming (code reuse, extensibility, maintainability, etc.) Indeed, most solutions are a combination of the two approaches, particularly when you're developing "end-user" apps (as opposed to third party apis or frameworks). But again, my objection to this book is that it leans way too far on the side of complex, bloated OO solutions versus much, much simpler alternatives. In some sense, this represents a larger issue in the dev community. That is, there's much more focus these days on business objects at the expense of efficient, high-performant data management. In other words, many developers value the business objects more than they value the database. Regardless of what anyone chooses to believe, the data will *always* be the "jewels" and it should have priority (from an architectural perspective) as such.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No