Developer Health Assessment

Developer Health Assessment

Old forum URL: forums.lhotka.net/forums/t/6867.aspx


saileshxs posted on Wednesday, April 29, 2009

I am new to CSLA.NET and our company recently had a "Developer Health Assessment" from Microsoft. We asked the consultant if he had any comments on the use of the CSLA methodology. The following is the reply we got which I don't think is right. Can anyone please help as I need to send their reply on to my manager and I think the answer they have given is incorrect.

"In regards to the CSLA, I wouldn’t categorise it as a methodology. It is more of an application framework, which provides you with some features you can use within your application, which is then backed up by a set of design guidelines as mentioned in his Business Objects book. I have seen mixed feelings when it comes to CSLA. Some people like it as it provides a prescriptive guidance on how to design applications and simplifies some basic tasks such as object persistence. But some other people say it is too prescriptive and they prefer to design their own application framework for implementing a domain model. They can then use other object persistence frameworks such as NHibernate or Entity Framework (aka LINQ to Entities). The new wave of technologies including LINQ and WCF have made creation of multi-tier applications with object persistence extremely easy so one could argue that you can easily achieve the same result by using .NET Framework components.

So as I said above, like any other application framework, there are mixed feelings about CSLA and one needs to take many factors such as business context, developer knowledge and preference into account to make a decision as to whether to use CSLA. "

ajj3085 replied on Wednesday, April 29, 2009

This is a common comment regarding Csla, it seems. To me, it shows a lack of understanding as to what Csla is and what role it's fulfilling.

Csla is NOT an "object persistence framework" at all. It's a business object framework, and there is a difference. Persistence frameworks focus is getting data into and out of a database. A business frameworks focus should be on business objects that satisify use cases and contain the business logic (validation and authorization rules). The persistence layer is a very poor choice of layer in which to codify business rules, because the objects in the persistence layer match the database... but if you're designing business objects to satsify use cases, many times the design can be radically different from how the data the use case utilizes is stored.

I was in a company that went down that route... building business rules into the persisistnce layer (our custom version of NHibernate objects). It quickly become a mess, and was very fragile WRT chances in use cases. Since moving that logic into a Csla based library, maintainability has been greatly improved, which is good because software spends most of its life in the maintence phase.

So no, you can't achive the same result using only .Net components. Anyone making a claim doesn't understand the two different goals of Csla and persistence frameworks. MS doesn't really have a framework appropriate for building business objects with.. they have a beta or V1 out now which is starting to move in that direction (I forget the name of the project at the moment), but it's not nearly as mature as Csla.

HTH

dlambert replied on Wednesday, April 29, 2009

Yeah, the comparison to other persistence frameworks is misguided, but other than that, the guy really didn't say anything at all of any substance.  He's a well-trained consultant! 

Despite saying nothing at all that's concrete, there's a veiled implication that CSLA somehow prevents you from taking advantage of new technologies.  I think I'd want to point out that in fact, not only does CSLA allow all these new technologies, in many cases it embraces and leverages them.  I'd challenge any WCF guy to whip up a multi-tier app quicker than a CSLA developer changing a config file to enable the same thing.  You may also want to mention SilverLight support and even the Oslo and M stuff that Rocky's been blogging about.

The only nugget of truth in there is that some people like CSLA, and others prefer to do everything themselves.

ajj3085 replied on Wednesday, April 29, 2009

dlambert:
The only nugget of truth in there is that some people like CSLA, and others prefer to do everything themselves.


Indeed.. and most that go this route, in my experience, seem to believe Csla is a persistence framework. :-)

DocJames replied on Wednesday, April 29, 2009

Hello,

If you take a look at Rocky's blog post Overview of CSLA .NET 3.6 for Windows and Silverlight you can see that CSLA can't be compared to a "normal" object persistance framework.

Jimmy

Tom_W replied on Wednesday, April 29, 2009

The other thing that I see repeatedly lobbed into the anti-CSLA argument is that CSLA contains a lot of functionality you don't need.  This is always confuses me greatly, surely every business app needs the majority of CSLA's features (validation, business rule handling, authorization, binding, etc. etc.).

The last major project we worked on (our first in .NET) involved writing most of this code from scratch, which is a huge amount of work - much more than we had envisiged.  The data binding code in particular is horrendous to write yourself, there are just so many undocumented features of .NET databinding. 

What we learnt from this experience was that it would have been far quicker to go up the CSLA curve than to write a custom framework.  Plus you get a big userbase testing the heck out of each version.

Even if you do ultimately decide to go for a custom framework, there is an awful lot of hard-learned experience in CSLA and Rocky's books that mean I would recommend going CSLA first just to get your heads around the amount of work that is involved.


saileshxs replied on Friday, May 01, 2009

Thanks to all that relied. It was useful to hear from experenced CSLA developers that the consultant had got it wrong.

I'll have a read through Business Objects 2008 book to come up with counter arguments to what the Microsoft consultant wrote.

RockfordLhotka replied on Friday, May 01, 2009

saileshxs:

The new wave of technologies including LINQ and WCF have made creation of multi-tier applications with object persistence extremely easy so one could argue that you can easily achieve the same result by using .NET Framework components.

If only this were actually true...

And it is true for web apps, where rich interactivity isn't possible like it is with Windows Forms, WPF and Silverlight. While CSLA offers some value in the web space, I think there's a good argument to be made that Microsoft's core platform can be used to get similar results.

As soon as you want a more interactive interface though - with Windows, WPF, SL, etc - then the core .NET platform simply has too many holes. They define how to fill in the holes, but they don't actually do it.

For example, the problem with LINQ, WCF, and ADO.NET EF is that the objects they create don't implement the necessary data binding interfaces. So to get the interactivity you really want in a normal application, you have to wrap these technologies with your own framework that does implement all the data binding, validation, business rule and authorization processing.

By the time you've done that, you'll have created a substantial subset of CSLA .NET :)

One idea I toyed with, and have thus far rejected, is tying CSLA directly to ADO.NET EF. The problem with EF is that it doesn't do what CSLA does. The problem with CSLA is that it doesn't do what EF does. Maybe they'd be better together?

But I keep rejecting this thought, because EF is a data access technology. And Microsoft has proven over the past 15+ years that they never really commit to any one data access technology. My fear is that if I bound CSLA to EF, then in a few years when EF falls out of favor, CSLA would get squished - and that'd be bad.

 

Copyright (c) Marimer LLC