Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Pros and Cons of CSLA
As with any framework, there are trade-offs to consider when thinking about using CSLA for your next enterprise application. Let's consider some of the pros and cons.
Pro: Alleviates overhead programming of enterprise development
CSLA takes away the burden of having to create a large programming infrastructure every time you undertake an enterprise application. Once you buy into CSLA, you never again have to worry about creating remoting architecture, implementing databinding support, or working consistently with hierarchical data in your objects. CSLA provides all the plumbing that you need.
Pro: Lets you program enterprise-level applications consistently
We have discovered that once CSLA became our application's development framework, it was very hard for members of the development team to stray too far from the pack in terms of coding style and design implementation. For example, after a while we learned that if we wanted to see how another developer was doing data retrieval, we only needed to look in the object's DataPortal_Fetch() method. Also, the creation of collections of objects and the saving of hierarchical data became a consistent experience. We did not have to devote precious design-time discussion to how we were going to make and support collections. CSLA gives us a roadmap that eventually becomes a design standard.
Pro: Provides flexibility in management of data sources and network protocol
Remember that CSLA stands for Component-based Scalable Logical Architecture. Not to be trite, but Scalability is CSLA's second name. The fact that data source location and network protocol are declarative settings in the app/web.config file provides a lot of leeway when it's time to move an application from working with data by way of a web service, to the faster-running operational environment provided by Enterprise Services. Granted, CSLA isn't magic, but it does reduce overhead in terms of environmental programming.
Pro: Includes very useful utility classes
CSLA ships with a bunch of utility objects that make working with the framework a lot easier. Listing 7 demonstrates the use of the ObjectAdapter, one of these objects. The ObjectAdapter will transform a strong-typed collection of CSLA objects into a data source.
Listing 7: ObjectAdapter class used to bind a collection to a control
//Get the a musicians BusinessBaseList MusiciansList musicians = MusiciansList.GetList(); //Use the ObjectAdapter to transform the list into //a DataSet ObjectAdapter adapter = new ObjectAdapter(); DataSet ds = new DataSet(); adapter.Fill(ds, musicians); //Bind the DataSet to the musician’s //DropDownList ddMusicians.DataSource = ds.Tables[0]; ddMusicians.DataTextField = "LastName"; ddMusicians.DataValueField = "Id"; ddMusicians.DataBind();
Also, CSLA ships with a SmartDate class that supports null dating as well as date texts. There is a DataMapper that allows you to map properties between objects or map an IDictionary object onto your CSLA object. And there is a SortedBindList that provides a way to sort collections. Lastly, CSLA comes with a SafeDataReader that converts null data into empty data or default values.
Con: Takes time to learn
Using CSLA is not intuitive. The framework has a considerable learning curve and requires a significant investment of time. You need practice to get the hang of it, particularly to take full advantage of the DataPortal functionality. CSLA is best suited for large projects in a distributed environment that will have a shelf life of many, many years. Mr. Lhotka's books are an excellent resource, but they are filled with detail, and every detail has an implication in terms of application design and writing CSLA code. Keep in mind that skipping a detail in the short term might come back to haunt you later. However, once you've got some skill with CSLA, the savings in heads-down programming time and quality assurance expense are significant.
Con: Requires OOP expertise
CSLA makes extensive use of the factory design pattern, reflection, serialization, generics, static methods, and programming using abstract classes. These are not beginner's topics. If you're planning to use CSLA, you'll find it advantageous to have at least one experienced person on your development team—someone who can write efficient, effective, advanced object-oriented code in the .NET environment. Otherwise, you run the risk of getting compile-time errors that are difficult to resolve, and runtime behavior that you won't understand.
Con: Demands comprehensive familiarity with the framework
CSLA is a framework, not a methodology—you have to learn it. And it's best to use the framework in the way it is meant to be used. You can use CSLA piecemeal, but in order to get full long-term flexibility and benefit from the framework, particularly in terms of the DataPortal mechanism, it's best to use all the parts of the framework all of the time. Otherwise you run the risk of having to go back and refactor code—definitely antithetical considering that avoiding refactoring down the road is what CSLA is all about.
CSLA is comprehensive but not magical. Although its benefit is that a lot of "plumbing" is already in place, you still need to know how to do things such as change an object state from new to old (invoke MarkNew()); how to declare an object as a child of a parent (invoke MarkAsChild()); and how to configure your environment so that a CSLA client application can work with a CSLA application server. These are detail-rich activities. Yet once you learn what you need to, you'll move much more quickly in subsequent iterations of your enterprise application.
Con: Uses reflection rather than interface method implementation
This is a fine point and one worth noting. As you've read here, the CSLA DataPortal requires that your CSLA objects needing data access functionality implement a few special methods that are called by the DataPortal at runtime. The usual object-oriented technique to ensure method implementation in a given object is either to have your object derive from an abstract class that contains abstract methods that must be implemented, or to provide an interface that your object can support. Thus, if you create objects that fail to implement a required method, you'll get a compile-time error.
The code in DataPortal, however, uses reflection to identify an object's specific data save and retrieve behavior. Undoubtedly Mr. Lhotka had good reason for including this functionality. That said, the use of reflection negates compile-time checking for the existence and implementation of these special methods. You do run the risk of inadvertently deploying some buggy code.