Customer Reviews

Expert C# 2008 Business Objects

5 star:		(5)
4 star:		(3)
3 star:		(3)
2 star:		(0)
1 star:		(2)

 

 

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!!

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.

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.

In this book, "the different and bold way of software design is introduced." We are people who USE it everyday. We agreed with some reviewer (who rated this item very low!) and their opinions are true! But they are NOT fully understanding the key concepts (Business Objects & CSLA) this book has introduced.

YES, that's right! The Business Object "violated" every principle of software design Eric Evans (in his book, Domain-Driven Design: Tackling Complexity in the Heart of Software) and Martin Fowler (in Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)) give. Both Evans & Fowler are geniuses and principles they give are valuable. The principles are prepared for SCALABLE and future CHANGES in business requirements by SEPARATING concerns called Separation of Concerns (SoC) into layers and components. But, different and bold, Business Objects & CSLA favors object inheritance, instead.

*** If you understand the concepts in this book, it uses inheritance to normalize object's behaviors instead of its data (Many developers use inheritance for data normalization as we do it for RDBMS). Behaviors Normalization is very interesting concept. ***

..............................................................................

-- "Business Objects" vs. "Evans & Fowler (E&F)" --

1. Concept Complexity -- Business Object is very complex concept and needs some time to study while E&F is simplified. In our opinion, both take some time to experience.

2. Scalable for Enterprise Application -- Both are doing well for this. (When we talk about enterprise application, we mean the application that applied n-tier concept, supported large users, and solved complex business requirements.)

3. Productivity -- We brought this up because we think Business Object has this advantage. The framework increases your productivity to create new application with rich features**.

4. Changes in Software Design -- Many people think Business Objects is inflexible because it favors inheritance. That could be so true, but depended on how you use it. If you use the Business Objects that is rich-featured** or fat-featured** for simple application that doesn't need those features, it'll be a bad choice. However, what we suggest is to learn the concepts in this book and implement your own Business Objects based on Behavior Normalization. What we did is we created our own several Business Objects using concepts from the book and use what is suitable. We also applied E&F in our Business Objects. It takes some time to create Business Object as base class for real Business Object. But once you have it, you can create real business object very fast and that gives you productivity.

While E&F is very flexible, but may not be simple as it seems. What we like about E&F is that it's made for changes (SoC, Cohesion, and Coupling.)

5. **Concept Focus -- When you try to compare these two concepts, you are easily getting confused. Why? Because they are different. Concepts of Domain Modeling and Enterprise Architecture focus on separation of concern for changes. What they separated is functionality, Each layer and class must have strong concern or responsibility and it must be lowest as possible. A class should have one reason (concern or responsibility) to change. While Business Objects focus on object's behaviors, and only deals with Business Logic Layer and Data Access Layer. We all know that dealing with BLL & DAL is painful.

There are a lot of interesting things to learn from this book. But this is too much to write here!

..............................................................................


** Rich Features, Business Objects provide
- Validation and maintaining a list of broken business rules.
- Standard implementation of business & validation rules
- Authorization & authentication
- Strongly typed collections of child objects
- N-level undo capability
- Simple model for UI developer, Data Binding supported.
- Simple model for Data Access

Last word, Don't buy this book if you don't expect to learn different software design. Business Objects is not the best practice, it's just a practice. Business Objects is not solution you're looking for. There are no one best solution for every problem, but every problem has one best solution. Business Objects does not create an application, it helps you create the application.

This book is written much better than its 2005 counterpart. The section are divided in such a way that you can read the book from cover to cover or skip to a section. This is a must read for any object oriented programmer, even those not involved with traditional server/client architectures.

This was a very interesting read. Yes, it documents the CSLA framework but the book provides more than that. For example, the chapter that includes WCF custom security modules provided a far better concrete than I discerned from reading Juval Lowy's book (which I thought was excellent as well) and there is not a whole lot of reliance on CSLA in those examples. The chapters on creating custom IPrincipal objects were very informative as well. Looking at the CSLA framework code, I learned methods of using generics that I have not seen elsewhere. Whether or not you wind up using the CSLA framework, there a good takeaways from reading this book.

This is not an ORM book or framework. It does not even remotely pretend to be ORM related. ORMs do not, generally, comprehensively implement the standard Microsoft interfaces (and more) for security, validation and UI interfaces for validation message display, data binding, remoting, LINQ integration, N-tier, command pattern, etc. CSLA.NET does. Most people skip the notion of developing true business objects and head straight for datasets, entities or NHibernate. The reality is that business objects are a logical tier on top of these data access technologies. I do admit that I would like to see the author take advantage of some of the hooks for custom objects in EF 2.0 which might provide some development productivity gains, but currently his focus is on Silverlight 3 functionality.

The book is quite lengthy, but rather than being "dummies" fluff, it is to the point and understandable, much like Juval Lowy's WCF book. And while long, it is possible to skip around the book a little bit. The first 200 pages are a must read before jumping elsewhere. The design portion which covers the design of CSLA.net may not be absolutely necessary reading and is a large portion of the book, but in the end you'll wind up going back to read it and it will provide a more thorough understanding of CSLA.net

The book covers the CSLA framework thoroughly, but it spends VERY few pages explaining how to use it. It does provide some downloadable examples which are covered in the final chapters.

The first chapters are interesting , then the author goes into the framework , and finally it provides some rather meek examples at the end of the book.

When purchasing this book expect :
1. A thorough coverage of CSLA
2. A detailed explanation on the design desicions of the framework.

Do not expect :
1. A tutorial
2. A cookbook
3. An easy to follow book.

The best anallogy I can find is suscribing to a driving lesson and then being taught how a car works and why it was designed the way it was and then receiving a very quick lesson on how to actually drive.

Barely acceptable.

Very happy with the price, quality and shipping from this seller. The retail price of this book was $59.99. I paid about $12 + shipping for it. The book was used but in very good shape. 5 stars!

So, the book is very well organized and written. The ideas are very clear and it actually make me think in the way I normally architect projects. Don't get me wrong, I'm not doing it that bad, is just it has opened my eyes to other possibilities and some better techniques.

With this book, it's clear that Rockford Lhotka is quite an expert in architecture and design.

Now, please, make sure you read the first book Beginning C# 2008 Objects From Concept to Code so you'll get a better and more pleasant reading experience.

Overall, I highly recommend this book if you are a software architect and/or work with n-tier projects or enterprise class projects.

By: Jose Rolando Guay Paz



-------------------
La estructura utilizada se adapta a las expectativas requeridas, los ejemplos varios refuerzan la practica del lenguaje. Las estructuras se pueden entender de manera facil. La explicacion detallada de lassintaxis fomenta su practicabilidad, asi mimsmo desarrolla y refuerza nociones sobre la programacion del lenguaje C#.

Las tablas presentan detalladamente las propiedades, descripciones, atributos, tipos, metodos, etc.

By: Marlon Joao Maaz B.


------------------------
Por la utilizacion de profesionales utilizando orientado a objetos C# veo muy util los objetos de negocios presentados.

Creo que este libro es muy completo ya que inicia con estructura, diseno de la plataforma, luego las aplicaciones y todo con muchos ejemplos. En general, muy bueno.

By: Hector Armando Macz Bac

There is a lot of valuable code in this book and the accompanying framework that allows you to write scalable enterprise solutions without a lot of effort, however.... The framework seems more complicated than it needs to be and almost necessitates the need for a code generator such as CodeSmith (which BTW is an excellent tool); I get the feeling that it is carrying some baggage from prior versions of the framework. Adding Silverlight support might be good for selling books or gaining points as a MS Evangelist for the faithful, but it adds unnecessary baggage to applications that don't need it and no, I don't plan on writing anything with Silverlight in the near future even if MS marketing is pushing it.

The .NET 1.1 version of this framework has IMHO a cleaner design even though it didn't use Generics or Linq. Perhaps it is time for Rockford to tear it all down and start over as he did when he went from VB6 to VB.NET.