I am seriously considering removing the CslaDataProvider types from CSLA 4 (in WPF and Silverlight).
The reason I am considering such a thing is that there is no support for the concept in the Visual Studio 2010 XAML designer, and Microsoft is clearly not going down the road of using or supporting the data provider concept in general.
One option is to remove it only from Silverlight. In WPF the concept still formally exists (there's a .NET base class, etc). But in Silverlight we made up the data provider concept on our own in CSLA .NET for Silverlight - roughly emulating the WPF model.
The thing is, the MVVM techniques are almost universally superior to the data provider concept. And it is possible to integrate MVVM into the VS10 designer, where it is not possible to integrate the data provider concept.
My worry is that leaving the data provider stuff in CSLA 4 will just encourage people to use it for new projects - which would be a poor choice. But removing it will break existing apps that leverage the technology - though those apps will be blocked from really leveraging the VS10 designer support, which is sad - so people will probably want to update those apps to use a more accepted concept anyway.
[Poll]
Could you leave it in for one more version and mark it as obsolete?
Could you leave it in for one more version and mark it as obsolete?
I don't think there's any real mechanism for marking UI components as obsolete.
So I can leave it in for one more version and try to make a lot of noise about its impending disappearance - but eventually I'm going to make some people unhappy - sooner or later...
Hello,
My vote is for removing it but not until v4.1 or v4.2. I have seen quite a bit of code that is dependant on it and removing it completely would deter people I think from upgrading right away especially because they are skeptical of all the changes .NET 4.0 will bring. The .NET framework guidelines state that you should mark something as obsolete for at least two versions before removing. If you set the attribute on the classes. VS should show a warning or build error even if it is a designer class.
Thanks
-Blake Niemyjski
For people that may have a problem with you removing this feature is it doable to move the CslaDataProvider functionality to an UnsuportedCode.dll?
This way, the folks that still use that functionality can reference that dll and don’t have their code break thus giving them some time to upgrade to MVVM.
I am guessing that other people may wonder the same thing?
Thanks!
Would any extra work be required if you decide to keep the CslaDataProvider? If not then its probably best to keep it and mark it as obsolete (as already suggested). I guess seperating the code in an "UnusedStuff.dll" is also a good point as this gives you the opertunity to maybe put some other items in there (like the WinfForm supporting list base classes 
)
I haven't tested to see if it works in SL/WPF 4, so there's a testing burden, possibly a maintenance burden. But the bigger issue is that people keep using it, and I'd prefer to steer people toward more broadly accepted alternatives.
The idea of a legacy project is not a bad one. I'd need to see if any internal members or interfaces are used, otherwise that'd be reasonably easy.
I agree with Blake. I vote we move forward and keep CSLA clean and simple however I need a small window of opportunity to migrate existing code to the new pattern. Would it be possible to get a brief step-by-step outline of what it would take to upgrade the Project Tracker example from the CslaDataProvider pattern to the MVVM pattern?
Thanks
Copyright (c) Marimer LLC