Expert C# Business Objects
In Building Object Applications That Work, Scott Ambler recommends that the business objects and their Business layer be designed ahead of the persistence layer and the interface layer. With that in mind, I worked through about two-thirds of Expert C# Business Objects.
This book has three parts.
The first part of the book looks at the .NET Framework and how its various strengths can be used in the design of distributed applications. This is the best part of the book, providing what may be the best available overview of the .NET Framework in the context of large applications.
The second part of the book walks the reader through creating the CSLA .NET system. This system creates a framework of “smart” business objects. These business objects know how to populate themselves with data, whether they are new or old (old meaning they already exist in the database), whether they are clean or dirty (dirty meaning that the data in the object has changed since it was retrieved from the databse), and various other things.
The third part of the book shows how the CSLA.NET framework can be applied to a Windows Forms application and a Web Forms application. At least, I think that is what the third part of the book talks about. I never got to the third part as I found the second part decidedly funky.
In an earlier weblog entry, I said that the genericity of open-source projects seems to lead inevitably to complexity. In its effort to be generic, the CSLA.NET framework has some very questionable aspects to its design.
One of the goals of the CSLA.NET framework is to support an application deployment where the Business layer resides on one computer (the client server) and the Data Access Layer resides on another computer (the application server). To support this deployment model, the CSLA.NET framework uses two Portal classes. One Portal is “anchored” to the client server, and the other is “anchored” to the application server. A business object will typically be running about the Business Layer. But when it needs to load or save data, it must visit the Data Access Layer. Because in this deployment model the Data Access Layer is on a physically different machine, the business object is “moved” (by Remoting) to the Portal that is anchored to the application server. After the business object has worked with the database, it is sent back to the Portal that is anchored to the client server, thereby sending the business object back to the Business Layer.
By itself, that seems like a pretty flexible approach. The two Portals provide a way of passing the business object back and forth between the client server (Business Layer) and the application server (Data Access Layer). If you think of a table-tennis game, where the business object is the ball, you’d have a reasonable analogy for the way this works. The problem with this setup, and to continue the analogy, is that the ball becomes extremely heavy.
A business object should be lightweight. It should represent something (such as a User) and allow actions on that something (such as getting the Roles of that User), but that is all it should do. The business object should not know anything about how it loads and saves data. Yet in CSLA.NET, it is the object that performs its own persistence. So the object is not only representing something, it is also charged with knowing how to load and save its own data. This is a mashing together of two separate concerns that a layered architecture is meant to prevent.
A second major problem is that the database code that gets shoved into the business object is database-specific—it uses Microsoft SQL Server. So not only is the business object performing its own data access, which it should not do, it has knowledge of the specific database being used, which it should not have. These business objects are accepting far too many responsibilities and, as a result, becoming very “heavy”.
In order to support both Windows Forms and ASP.NET applications, the CSLA.NET has many other aspects that lead to it being very complex. So the CSLA.NET framework that is developed in the second part of the book is so generic yet so complex that it seems vaguely right for anyone but actually right for no-one.
The book is definitely worth reading. Its discussion of .NET, distributed applications, and business objects is very, very good. However, the framework that the book builds seems an example of both what to do, and what not to do. For this reason, Charlie has taken cues from CSLA.NET, but has certainly not implemented that framework.
by Alister Jones | Next up: Charlie’s First Code →
----
Post a Comment