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. "
dlambert:The only nugget of truth in there is that some people like CSLA, and others prefer to do everything themselves.
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
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.
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