I have brought in a consultant to help nail down some architecture decisions that will be the basis for major software development projects here for the next few years. One of the reasons I selected him was because he has done extensive work on a framework to solve some of the problems CSLA addresses, albeit in drastically different ways in many cases. He has no knowledge or experience with CSLA other than my descriptions.
So, we've discussed the merits of both approaches for several hours and we're at the point where I've said we're going with CSLA unless he can come up with specific overwhelming arguments otherwise. We're having that discussion later this week.
He has made the statement something to the effect of "yeah, the book may be 600 pages, but that's mostly discussion of the problems and when you boil it down to the actual solutions there's just a few hundred lines of code. I've also had to solve many of those same problems and also already have the code to do so. In the other cases we can just use the CSLA code as an example solution. And I've solved some other additional problems."
So, my question is... if anyone else has been in these conversations, in that context what are the "big" aspects of CSLA that seem to get overlooked or for which the significance isn't fully realized? One example is the DataPortal channel pattern implementation. This consultant accurately described configurable remoting as just making a class MarshalByRef and designating it runs remotely in the configuration file. Sounds simple enough, but of course, that's really a pretty significant oversimplification of the whole problem.
Rocky, I'd particularly like to hear your input on this since I would imagine you/Magenic sometimes finds itself "competing" against an alternative approach. What are the compelling arguments for CSLA vs. the alternatives.
Let me be crystal clear about this - I am not talking about the merits of n-tiered applications or of CSLA vs. datasets, etc.... I'm specifically talking about CSLA vs other similar business layer frameworks - or maybe not so similar but solving many of the same enterprise architecture problems.
My experience over the years has been that sometimes (like the DAAB) there are $10 solutions to $.25 problems, but other times you think something isn't really that complex but when you try to do it yourself you run into new problem after new problem at every turn. And, the consultant's framework is more of a complete application builder and my experience with them in general is that you find yourself dealing with exception after exception until you've lost much of the benefit.
So, there's a lot of stuff in there and I just open the discussion for anything anybody wants to add.
Well, not knowing exactly what the "others" are the most obvious advantage is you have resources like this site where you can find solutions to basically any issue you may have with CSLA for free ;-) If you use some consultants custom framework (even if it is better) as issues arise you'll probably have to keep paying him to address those issues. So the huge community of free support is a pretty big advantage.
Also, as the technology changes Rocky and this community have proven they will keep updating CSLA to the latest technology for you for free (not that transitioning is always 100% painless of course). Say your consultant makes an arcitectual decision to go with remoting and then 10 years down the line MS decides to discontinue support of remoting. Again, you'll have to do a pretty custom upgrade where the CSLA community will most likely have a free version availble to use the latest/greatest (whatever that is).
My $0.02 worth here is this:
I have about 25 years in development, I have done Assembly, Pascal, dBase, CLipper, VB3-6, C, DOS, Linux and so on.
Yes CSLA is not "Magic" and I am sure that other could create a framework that would do many of the same things etc...
but it does work, it has been tested, it has a community that supports it, it uses standard .net "stuff"
I just started with my first CSLA project, I am also using CodeSmith, I wish I had them a year ago.
I have looked at a *LOT* of Code and my take is this is top-notch code here!
That’s funny Dan, because I just got this (slightly edited) email, which is along the same lines:
I came across the CSLA-book and read the most part of it and was impressed and overwhelmed. I heard about the MereMortal-framework and was impressed and overwhelmed. Can you make my choice easier? Are there three compelling reasons why I should choose the CLSA-framework?
Here’s my (unedited) response:
Let me start by saying that I have no vested interest in convincing you to use CSLA .NET as a framework. The only money I make out of this is through book sales, not from the framework itself.
I wrote the book as a teaching tool - in an effort to show at least one way to solve a set of complex problems around building an object-oriented business layer that supports Windows, Web and Web Services interfaces in an n-tier client/server environment. The framework itself is a fortunate side-effect of the book, and thousands of people have found the framework immediately useful in their work.
There are numerous frameworks/tools out there, CSLA .NET, nHibernate, Spring .NET, Mere Mortals and many others. Each one takes a different approach, based on the philosophy and experience of its creators. I think it makes no sense to arbitrarily reject any of them as being "bad" or accept them as being "good". They are all useful and can be beneficial.
What is more important, imo, is that you agree with their underlying philosophy, because that is what leads to success or failure.
A framework is merely a codification of a set of architectural standards. No one starts with a framework - we all start with a view of software architecture and design that we think is "right" or at least that we think works well. From there we formalize those views by creating a framework or tool (or both) that makes it easier and more productive to build an application following the architecture/design that we envision.
So if you agree with the architecture/design philosophy behind a given framework, then you'll likely enjoy using that framework because it will help you. But if you disagree with the philosophy, you'll find that you are always fighting with the framework, trying to make it do things in a way it was never designed to support.
For instance, CSLA .NET is designed to support responsibility-driven, or behavioral, object oriented design. While it can be used with more data-centric object models for simple tasks, people following that design approach run into trouble as they get further into their project. Classes either become overly complex, or performance issues appear. The reason this happens is not because CSLA is "bad" or "good", but rather that it is being used with a different design philosophy from mine - and CSLA is designed to reflect responsibility-driven, behavioral, object-oriented design.
Other people, who work to follow responsibility-driven design for their object model, typically find that CSLA offers tremendous benefits in terms of developer productivity, maintainability of code and overall flexibility of the application over time. Honestly, I believe that much of the benefit comes from having a good object model, but there's no doubt that CSLA makes it far easier to create powerful objects to support various types of UI and various types of n-tier deployments than if you had to write the code by hand.
As for three reasons, there are different aspects to that question.
From my perspective:
1. Supports responsibility-driven, behavioral, object-oriented design
2. Maximizes the focus on business code, not on "plumbing" code
3. Abstracts powerful .NET features, making them more accessible
From a business perspective:
1. Reduces the cost of application maintenance
2. Decreases the cost of application development
3. Maximizes flexibility, enabling business agility
From a pure technical perspective:
1. Enables Windows, Web and Web Services interfaces
2. Supports 1-, 2- and n-tier physical deployments with no code changes
3. Provides a light-weight, non-intrusive framework within which you write your code
For more information you can visit my web site at www.lhotka.net. The framework home page is www.lhotka.net/cslanet. You might find the following article of interest
http://www.lhotka.net/Article.aspx?area=4&id=e6d603c6-9a1a-4a9f-94af-dcbb2f0a75d0
Also, there's a very active online forum around the books/framework at http://forums.lhotka.net, where you can find hundreds of people discussing topics from OO design, to using CSLA .NET, to using features of .NET itself.
Hopefully this is helpful to you in making your decision.
Dan,
Not sure what framework that consultant has, but since Mere Mortals was brought up, I thought I'd offer a little comparison between MM and CSLA.
I'm no authority on frameworks, OO principles etc., just a guy looking for tools/frameworks that will make my job easier.
I used MM for a while - this was the .NET 1.1 version. I was pretty impressed, and thought it was worth the $800 per developer to purchase - you'll make up that money in develpment time easy. Then I went out on my own and was looking for something, well, cheaper :). I think I paid about $50 total for the CSLA book and e-book. You also need to spend about $300 per year to keep your MM subscription going.
Now I haven't used the remoting features of CSLA, and don't remember that being part of MM. I also don't remember n-level undo in MM. Besides that, from my perspective, they're pretty similar in the features they give you - business objects, business rules, the easy of just saying .Get and .Save in the UI. MM does have one feature that CSLA doesn't provide that was great for demo's - the end user, given the priviliges, can set the security on controls during runtime.
For better or for worse, MM relies on DataSets heavily. I'm probably giving a simplified explanation, but a business object in MM is a DataSet (actually a mmDataSet - derived from DataSet), which is wrapped and a bunch of functionality added. I don't know enough to be able to converse about the pitfalls of DataSets, but I know there's opposition to them.
There are some things that I don't like about MM. There's no book, just a couple sample projects. The forum is not nearly as active or interesting as this one. Plus, since it's hosted at Universal Thread, you have to pay UT if you want the full forum features like searching back more than a month, email notification etc.
Also, there's some, dare I say, tight coupling going on with MM. To be able to use grids etc., you need to use the author's subclassed controls. While he provides this, it's only for the built-in .NET controls and Infragistics. When Infragistics puts out a new version, you have to wait for the new MM version to support it - unless you want to write the code yourself.
I'd rather use either framework than nothing at all. But I can't justify spending the extra money for MM.
Mike
Thanks everyone for your thoughtful input.
Rocky, thanks for that. I think it should be specifically noted that your CSLA work and books are probably just as valuable for shaping and challenging the mindset about business layers as it is for providing a working framework. I don't even waste my time really arguing about merits of a CSLA-like approach vs. dynamic/ad-hoc/ORM/dataset kinds of thinking - not because CSLA is clearly superior and they're idiots but because they're just philosophically different presuppositions as you stated.
This particular discussion I've having is based on the premise that things like those 9 points you listed are common enterprise development problems that everyone who's been coding for a few years and wants to have maintainable and efficient code for an enterprise application should be thinking about. I'm speaking of a case where this alternative framework developer would go down those 9 points and they would all be checked as already included (possibly in a superior way), or fairly easily solved. In his mind at least - which is largely the basis for my question of what areas of CSLA do people tend to underestimate in regards to complexity or difficulty of the problem.
For further information, in my particular case this alternative is one man's vision and work, even though he is an exceptional analyst and developer. As I said it is more of a complete application builder rather than a business framework, but that does include issues like being limited to whatever custom controls are included and replacing the standard Visual Studio forms designer for a custom one. All of these superior of course in his mind but I am not so clearly convinced.
Here's what I feel are those somewhat intangible advantages of CSLA in this specific context:
Regarding MM specifically, by "the end user, given the priviliges, can set the security on controls during runtime" do you mean the privileges about whether the control is visible or editable? If so then that would seem to be a classic case of putting logic in the UI that belongs at a lower level.
DansDreams:
Regarding MM specifically, by "the end user, given the priviliges, can set the security on controls during runtime" do you mean the privileges about whether the control is visible or editable? If so then that would seem to be a classic case of putting logic in the UI that belongs at a lower level.
Yes, I mean that, for example, an administrator can set the authorization rules for a property while running the application. So a text box can be editable for certain groups/users, read-only, hidden for others. Like I said, it does demo really nicely.
What it does behind the scenes is stores this info in the database, and the business object checks for this data. So I don't think it's putting logic in the UI. It's just a built-in UI interface for setting authorization.
If you go to the MM site, you can try out an evalutation version, if you're interested.
Regards,
Mike
Yes, I mean that, for example, an administrator can set the authorization rules for a property while running the application. So a text box can be editable for certain groups/users, read-only, hidden for others. Like I said, it does demo really nicely.What it does behind the scenes is stores this info in the database, and the business object checks for this data. So I don't think it's putting logic in the UI. It's just a built-in UI interface for setting authorization.
I think that's the same thing Mike is saying. To the user it looks like he's editing permission on a textbox but he's really setting permission on the underlying business object property.
That would seem to get messy or confusing though if the property were displayed on more than just that one form. And I don't know MM, but I find many people from the data-oriented way of looking at things base their entire paradigm on the idea that even complex enterprise applications are really just fairly straightforward CRUD operations on a database and reports. Such a simple idea to us like being prepared to have the same BO data show up on numerious forms can be a mind-boggling concept to them.
Speaking of linking AddAuthorizationRules() to a database, I'll point out that with the current validation rules mechanism this is possible for business rules as well and having a metadata based rules engine of sorts was discussed quite a bit back when it was introduced.
One thing that's interesting talking to this other developer - He's very metadata oriented in his solution, with all the authorization, permission and rule information being read from a metadata source as a general rule. As Rocky's post illustrates, one thing about CSLA is that in many cases like this it really doesn't lock you in to a particular way of solving the problem... there is support established for a generic OO way of solving the problem and one particular specific implementation may be provided, but often with a few lines of changed code you effectively have an entirely different implementation. One of the fascinating things I've found in talking to people about their pet solution (present company here excluded) is how irrational they can be in defending running 20 lines of code in this place at this time compared to running almost the exact same 20 lines of code in that place at that time. :)
I think that's the same thing Mike is saying. To the user it looks like he's editing permission on a textbox but he's really setting permission on the underlying business object property.
That would seem to get messy or confusing though if the property were displayed on more than just that one form. And I don't know MM, but I find many people from the data-oriented way of looking at things base their entire paradigm on the idea that even complex enterprise applications are really just fairly straightforward CRUD operations on a database and reports. Such a simple idea to us like being prepared to have the same BO data show up on numerious forms can be a mind-boggling concept to them.
Speaking of linking AddAuthorizationRules() to a database, I'll point out that with the current validation rules mechanism this is possible for business rules as well and having a metadata based rules engine of sorts was discussed quite a bit back when it was introduced.
One thing that's interesting talking to this other developer - He's very metadata oriented in his solution, with all the authorization, permission and rule information being read from a metadata source as a general rule. As Rocky's post illustrates, one thing about CSLA is that in many cases like this it really doesn't lock you in to a particular way of solving the problem... there is support established for a generic OO way of solving the problem and one particular specific implementation may be provided, but often with a few lines of changed code you effectively have an entirely different implementation. One of the fascinating things I've found in talking to people about their pet solution (present company here excluded) is how irrational they can be in defending running 20 lines of code in this place at this time compared to running almost the exact same 20 lines of code in that place at that time. :)
![Big Smile [:D]](/emoticons/emotion-2.gif)
Yeah everyone has some idea they hold dear... and they can be very level-header and logical about most things but go all crazy when you question that one thing
Dan,
I believe the answers you seek lie in the very detail that you have not provided in you messages. You said these are major projects to be completed over a few years. The question is who will be architecting, desiging and coding them and what is their experience. I know that you have been a part of the Csla community for a couple of years. I would give that a considerable weight. Having single handedly completed a rather major WinForms app, which has now been in operation for over a year at several sites, I can tell you that you absolutely cannot go wrong choosing Csla.
I am now creating a Web UI for the same App while bringing everything into Csla 2.0, Sql 2005, Asp 2.0. A day doesn't go by without me marveling at how elegant this Csla is.
Jav
Dan,
I believe the answers you seek lie in the very detail that you have not provided in you messages. You said these are major projects to be completed over a few years. The question is who will be architecting, desiging and coding them and what is their experience. I know that you have been a part of the Csla community for a couple of years. I would give that a considerable weight. Jav
Indeed. That's part of those intangibles I mentioned. It's becoming rather clear now to me that using this 100% custom framework is not prudent. It may be the case that in 18 months this guy is introducing the most revolutionary application building tool the world has ever known and I could have been using it to write our applications, but the reality is I'm not putting my company at the kind of risk necessary to go down that path.
I've used the analogy of the automobile industry. Imagine I'm starting a cab company and somebody comes to me with a vehicle he builds in his garage that has advantages over what's offered by the big auto companies in several key areas, but is questionable in a few others. It uses standard parts from other manufacturers so all the individual components look familiar, but they're put together and utilized in unconventional ways not so readily apparent. I'm not a big enough risk taker by nature to go down that road. For better or worse, I know if I buy Cadillacs that at least I have lots of service options and any trained mechanic with even minimal experience will understand it fairly intimately the first day.
Dan
This thread reminds of the story of the Hammer Factory. If you are not familiar with the piece i suggest u go to
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12
Always worth a read when the subject of frameworks comes up, and most other times when you need a chuckle
Simon
Copyright (c) Marimer LLC