|
Book Title: Expert C# 2005 Business Objects
Published by: Apress
Written by: Rockford Lhotka
Overall, very good book.
The book describes the general principles of making an application framework in C# with some overview in the first few chapters. Actually, the whole book is designed to promote one proprietary standard called CSLA.NET framework which the author of this book heavily uses and even resells to everybody interested in. Indeed, very clever endevour. I should make one too and earn some money from it!
It's all about reuse and maintainability in this book, as about object-oriented application models. I didn't know actually that this topic is so well described and conceptualized, as I've dwelwed through this models in my recent works without knowing that it has theoretical background.
In the first couple of chapters, there is a brief description about some keystrokes about object-oriented app models and business models that a person should know - about complexity, relationships between logical and physical models, layered architecture (phew, through time those layers just got increased and then decreased, don't they?), and so on. There are also some tips on how to build optimal performance and scallable thin, smart, rich client, or web client, and afterall, the description of business objects in general.
It's interesting world about business objects indeed, they are powerfull and reusable, natural to use by humans, and very creative in design. Moveover, they should be able to have with the following attributes:
1. N-level undo capability (jeez, I've just couldn't make this until I've read those recipe!),
2. Tracking broken business rules to determine whether an object is valid (also very helpful thing!),
3. Tracking whether an object's data has changed (is it "dirty"),
4. Strongly typed collections of child objects (parent-child relationships),
5. A simple and abstract model for the UI developer,
6. Full support for data binding in both Windows Forms and Web Forms (fortunatelly, there are WPF and Dynamic Data coming into the scene to make us skip this design effort),
7. Saving objects to a database and getting them back again (of course, through binary serialization),
8. Custom authentication (I didn't find any good example to use it),
9. Integrated authorization rules (also),
10. Other misc features....
For this review, I had luck because I've already known two solid frameworks in my work, one self-developed, and one developed by other developers before me. So in the following text, three fws will be depicted:
1. Business objects framework developed by myself, let's call it 'A',
2. Business objects framework developed by very enthusiastic (and maybe too bleeding-edge devs) developers, let's call it 'B',
3. Business objects framework developed by Rockford Lhotka, that is, CSLA.
This gave me an advantage to be able to differentiate those two (actually successful ones) with this from Mr. Lhotka, and this is what I've found..
N-Level Undo Capability
Frankly, this gave me a headache before. In A I didn't (luckily) even dreamed to develop it, but in the B, I've seen the tremendous endeveur to code such a monstrum. But, fortunatelly, Lhotka solved it very neatly. By using serialization and stack structure with the history of objects (i.e. states of the objects). So, everytime the action is made, some specially decorated fields in objects are serialized and copied into the static stack. After some undo action is called, the object state is discarded and those archived statii were restored from the binary. Very good.
Tracking Broken Business Rules
Also, I didn't code it like that, and framework B did it but again in somewhat weird manner. But, firstly, let's explain what's all about.
The fact that a given piece of data is required in treated as conforming a business rule. If it doesn't, it's said that it has broken business rule. This apparatus should be very dynamic and instant, that is respond to some events (and ofcourse) with delegates.
In the framework B, the concept was the following: Each business object was inherited from some ObjectBase, which in turns is element of each app module. The problem was that the code couldn't differentiate about WHICH particular object and therefore object's event was fired, and that caused the mess (and repetitive method calls which caused dramatic decrease of app performance).
In the CSLA, Lhotka uses the collection of business rules kept within each object and fires the events from that object, which in turn switch the 'brokenage' on and off. Also, what made me even gladly, the messages are localized using standard satelite assemblies approach (in contrary of B, in which the texts were in the database!).
Tracking Whether the Object Has Changed
Well, here I've made the best solution because it's the most light and simplified than other companions. The fact that the object should be marked as 'dirty' and therefore treated to be savable is not more than just a few variables away. Sorry, Lhotka (and guys in B).
Strongly Typed Collections of Child Objects
Also, I've made it better and simplier (as Lhotka). The solution in framework B I should not mention. Only to make the note, each time the object should be called, ALL related objects (therefore their properties, events, etc.) are called and fired and ... well, guess what has happening.. perf curve was so bad...
Mobile and Anchored Objects
This concept is astonishing! It's described heavily in Chapter 4 (Data Access and Security) with the terms of DataPortal and proxy classes needed this to work. Well, I'm surprised that this could be done in this way. Although, a little bit too complex for me, but it works! It uses serialization (relative similar process and remoting) to create proxy classes which then are shipped accross the network to client and there changed and, either only referenced or just copied back to the client. There are lots of infrastructure built here, such as data portal, channel adapters, message routers, but in turns, it provides distributed transaction support, context and location transparency, and much more.
Supporting Data Binding
Data binding is one good concept but it has one constraint and that is - if the data is 'bound', what can we do to have more control in such manner that the data sometimes are not really connected to the UI elements and how to increase the speed on data flow (if it is not perf-friendly). This drama we had with the framework B in which the data was toooo bounded using some custom-made UI parser. Ah yes, I was trying to avoid this as long as I could but the future is in data binding, that's for sure. Pitty.
Well, WPF has data binding (and as I've seen very neat), and ASP Dynamic Data is coming too (and I'm also very enthusiastic about it).
Business Object Creation (Factory Pattern)
To instantiate the object, CSLA uses so-called Factory Pattern which by-design doesn't allow the object to be instantiated with the constructor, but rather using one predefined 'factory' method. For example, to create an instance of the customer object, instead of typing:
Customer c = New Customer();
we should call the predefined method like:
Customer c = Customer.NewCustomer();
To retrieve some existing customer, we should use also a 'factory' method which specially gets the customer for us, like:
Customer c = Customer.GetGustomer(criteria);
On contrast on that, in framework A I've used the constructor but with one (obligatory) construction with the provided object identifier. If this identifier is zero (or of those kinds), the object is treated as 'new'.
Like in the example:
// we create new customer
Customer c = New Customer(0); // instead '0' we could put 'null'
or
// we call existing customer
Customer c = New Customer(1234);
The benefit in this approach is that all logic is encapsulated in one method (constructor) instead of two (factory methods):
public void Customer(Guid id)
{
if (id == Guid.Empty)
// treat it as new - clear all fields and set the default values
else
// treat it as old - fill the values from the data store
}
Further Lammentations
Isn't it great to write a book about something you've coded and then spend the second half of the book explaining on how to use it? Wow. Lhotka made it! From the chapter 5 and 6 and on, he explains everything what he's done by creating one rudimentary example application in which this CSLA.NET framework is used.
Also, he has very sympathic web site in which he answers the questions from the developers, and actually sells his knowledge about something he invented.
And what we actually know about the creating the frameworks? Is there a payoff in building such thing (except make bucks in selling book and consultancies)? There are in history lots of tries to build such a monstruous 'framework of all frameworks to unite them all...". And they all failed...
I call it - the Tower of Babel. And in those times when the projects are more and more shortened, when the developers are not anymore 'only developers' but rather consultants, working on couple of mainstream and subsidiary projects and doing the community work (like this one ;) ), it's very hard to tell this is worth the try.
I challenge you..
|
