In SL, I need to do some last minute things to the object AFTER the user clicks the Save button. Since the CslaDataProvider directly invokes the Save method, is there an event raised that I can use?
This probably isn't what you want to hear, but the CslaDataProvider is no longer the recommended approach, and this shortcoming I think is a good reason why. The solution would be to move to a MVVM implemention, and you should be able to do this in the ViewModel. I'm not sure I really see any other way though.. maybe someone else does?
Thanks Andy. After posting my question I realized that ultimately the Save operation has to go through my DataPortal_xyz methods. What I need to do to my object can easily be done there, just before I call the AddParameters() method.
I have not looked into the MVVM approach because of time constraints in getting this project finished on time, and this issue would not prompt me to change. But are there any other compelling reasons to go to MVVM while using Csla?
Ah, well if you can do it in the DP_xyz methods, that's much better.
Better testability is one of the main reasons, as is eliminating code-behind from your Xaml files. Then there are things you'd want to do but can't, because the DataProvider limits you. Oh, and MS is quietly dropping support for it, as its not utilized in VS2010.
Oh, and MS is quietly dropping support for it, as its not utilized in VS2010.
Okay, now you are scaring me.
Can you suggest a quick route to plugging in a minimal MVVM into an ongoing project - just something with the smallest footprint. I tried educating myself but the plethora of info out there is enough to turn one's stomach. Thanks
Technically you wouldn't have to go completely MVVM to be safe.
The ViewModel<T> base class in 3.8 and higher is actually very similar to the CslaDataProvider in many ways, and switching from a data provider to a ViewModel<T> subclass is probably not that big a mental adjustment, nor would it have huge impact on your code.
The complexity of MVVM comes in when you say that you want to enable testability of your viewmodel code. That decision imposes a great many extra constraints on your code and how it is designed and implemented. I generally think those constraints are good, but they'd almost certainly have a major impact on existing code.
I personally go further and suggest that there should be zero lines of code-behind. That's not a goal of MVVM, but I think it should be a goal of any XAML-based app.
However, to come back to your situation with existing code and a tight schedule, it might be worth exploring the use of ViewModel<T> subclasses in place of your data provider controls. That change shouldn't require a tremendous effort, and even this small change can provide some pretty nice benefits - especially in WPF, but also in Silverlight.
The simplest ViewModel subclass is pretty simple:
public class CustomerViewModel : ViewModel<Customer>
public CustomerViewModel(int id)
This is for Silverlight. If you are doing WPF the BeginRefresh() calls could (optionally) be DoRefresh() which is synchronous.
Either way, when the refresh operation is complete the Model property is automatically updated with the new business object - just like the Data property is updated in a data provider.
The big difference is all the nice protected virtual methods you can override to find out about errors, that refresh is complete, save is complete and so forth. And all the public properties like CanSave, CanCancel and so forth - all designed for easy binding to UI elements so they can enable/disable/collapse as appropriate.
Thanks Rocky. This was of great help. I will need to study the MVVM Demo in the 3.8.2 Samples to get a good grasp of what goes where, for example the DataBinding expressions and how to make the Save and Cancel calls. As I recall, in one of the SL Videos you mentioned something about the topic - or may be I am just imagining it. I also seem to recall that you had a couple of blogs about the topic.
Copyright (c) Marimer LLC