Designing CSLA .NET

>Designing CSLA .NET

One of the characteristics of .NET is that it often provides several ways to solve the same problem. Some of the approaches available will be better than others, but the best one for a given problem may not be immediately obvious. I've spent a lot of time trying various approaches to distributing objects, and several of those have proven to work, but in the end I've arrived at the one that best matches my original goals.

Before I discuss those goals, I think it's important to talk about one other issue that I wrestled with before starting this book. Because .NET does so many things differently from the way COM does them, I found myself left with a choice between writing two rather different types of business objects book.

The first option was a book that showed how to translate or implement COM-based CSLA in the .NET environment. This would be useful to people who have built VB6 applications based on this architecture. Unfortunately, it wouldn't really show how to use the capabilities of .NET, because it would be focused on applying COM-style concepts in the .NET environment.

The other option was a book that focused on using .NET to build distributed object applications. This would be useful to anyone wishing to build object-oriented applications in the .NET environment, and could show how to take full advantage of the new technologies.

In the end, I decided to go with the second option, and to create a fully .NET-based distributed object architecture that takes advantage of all that .NET has to offer. For readers of the VB6 books who would like to port their applications to .NET, I have some articles on my website at http://www.lhotka.net that offer some insight into the best ways to perform such a task. This book should also be useful because it takes the same object-oriented and component-based concepts, and shows how they can be implemented far more easily in the .NET environment than was possible in COM.

>As I started researching and writing toward this end, I developed a set of goals for the architecture and the book. These goals are important, because they're key to understanding why I made many of the choices I did in terms of which .NET technologies to use, and how to use them. The goals are as follows :

• To support a fully object-oriented programming model

• To allow the developer to use the architecture without jumping through hoops

• To enable high scalability

• To enable high performance

• To provide all the capabilities and features of the original CSLA, namely:

  • n-Level undo on a per-object basis (Edit, Cancel, Apply)

  • Tracking of broken business rules

  • Support for many types of UI based on the same objects

  • Integration with MTS/COM+ for transactions

• To simplify .NET by handling complex issues like serialization and remoting

• To use the tools provided by Microsoft, notably Intellisense and autocompletion in Visual Studio .NET

Of these, saving the developer from jumping through hoops, that is, allowing him to do "normal" programming, has probably had the largest impact. In the COM-based CSLA, the developer had to write a lot of extra code to track business rules, implement n-Level undo, and support serialization of object data. All this code was important, but it added nothing to the business value of the application.

Fortunately, .NET offers some powerful technologies that help to reduce or eliminate much of this "plumbing" code. In several cases, this goal drove my architectural decisions. The end result is that the developer can, for the most part, simply write a normal C# class, and have it automatically enjoy all the benefits of n-Level undo, business rule tracking, and so forth.

It has taken a great deal of time and effort, but I've certainly enjoyed putting this architecture and this book together, and I hope that you will find it valuable during the development of your own applications.