OK, I have about two month casual familiarity with CSLA and I thought it was a good implementation.
That was until I was hired by a company as a consultant and looked at their adoption of CSLA for quick time constrained development. Their main focus is to use WCF Services in a very complex inmessage and outmessage scheme with a pipeline of http handlers for things like validation that leads to a SOA architecture, but this was too complex to get 50 or more developers up to speed on and takes more time to develop and is probably 50% done.
Thus CSLA and a WCFPortal was chosen. However, even though Rockford mentions that it is physically possible to separate Business Object implementation from the client and alludes to other threads that give suggestions on how to do this (through Interfaces etc), I don't see an easy architecture that doesn't increase the complexity to the point that the customer might as well bite the bullet and develop each busines object with WCF right now (instead of as it becomes ready).
The reason I say this is that when I looked at their Windows client, I see a reference to the Business objects which is necessary to access their properties and static methods like Fetch. However DataPortal_Fetch is defined in the same project (and in fact same class) because it is invoked on the other side of the portal. The customer therefore has a reference in their Business objects to their DAL (based on MyGeneration) and in many cases they have simply done direct stored procedures in the DataPortal_Fetch. If you reference the DAL in the business objects, the DAL assembly needs to be put on the client too.
This means the entire server implementation (3000+ classes) is exposed to the client, including the DAL and stored procedure names. I don't have to tell you that inteface/factory based .NET remoting and Web Service programming and the new customer WCF model mentioned above do not have this issue. This is a huge security issue for this customer with 2500 installations.
Even Rockford's own example CSLA projects shows that the ProjectTracker.Library is a reference in the Windows application thus exposing his own DataPortal_Fetch routines that use stored procedures.
So the question is: what are people doing to decouple the Windows client from the business implementation and why CSLA when WCF is clearly a better solution in that regard? Why was CSLA not designed to separate the CSLA client logic from the server logic i.e. why were DataPortal.Fetch and DataPortal_Fetch not designed to go in two different assemblies? IMHO it could have been done that way.
What am I missing?
You really need to read Chapter 1 of the Expert 2005 Business Objects book. That chapter explains the architectural philosophy behind CSLA .NET and would clear up a lot of your confusion.
CSLA is a layered architecture. It helps maintain separation beween the UI layer and business layer.
That is not the same thing as tiers, which imply physical boundaries (cross-process or cross-network).
CSLA is designed to enable the creation of applications with rich, interactive user experiences. You can't have that if the business layer is deployed only on the app server, because any user input must round-trip to the app server for business process (validation, authorization, calculation, data manipulation, etc).
Putting all the logic on a server is the mainframe and pre-AJAX web model. Not a bad model from a techical perspective, but really terrible from a user experience perspective.
If you want a terminal-based user experience, then you are right, CSLA may not be the ideal solution. It is designed to enable the exact opposite effect - a rich, interactive user experience.
Obviously people do put "all" their business logic on a server and still provide a rich user experience. They do so by duplicating the business logic (not all, but a lot of it) into the UI. And without any basis for sharing code between the client and app server, this code really is duplicated - write twice, maintain twice - what a terrible architecture!!
CSLA allows you to write a set of objects that run on both the client and server. You write the code once, and run it in both locations. Write once, test once - a much better architecture.
Using various techniques, it is totally realistic to have extra behaviors that exist only on the server. This is quite common, because some business logic really can't (or shouldn't) run on the client. That's fine, and CSLA supports that as well.
But to say that "thousands of server objects are exposed to the client" is inaccurate - in the CSLA model anyway. The CSLA model specifically shares the business layer betwen the client and server. That is the point of mobile objects. They are not "server objects", they are the business layer - and that layer runs in both places.
The cross-network API is the data portal, which has exactly 4 methods and is somewhat RESTful. It offers a single point of entry, limited verbs and a stateless model. All server requests are well-formed and follow a consistent pattern. The fact that the queries aren't text-based URIs is the only reason it isn't truly REST - but the pattern is the same.
So really, the server API in this case is much simpler than what you'd likely create using raw WCF. Most people using WCF re-create the massive COM+ style APIs from the late 90's - and those were not fun!
Copyright (c) Marimer LLC