According to Microsoft, they recommend two asynchronous patterns to follow in our code:
That said, I see a third option missing and it is the callback approach used for the CslaDataProvider in CslaLight. However, I find that the current implementation is very presumptuous and limiting.
My request/suggestion for the future would be to decouple the CslaDataProvider from the DataPortal. Right now, the callback methods are expecting to use the DataPortal arguments, etc. For one, the Data Portal is supposed to be an abstract concept for our UI developers, but having these types used in CslaDataProvider means that the UI guys need to have some knowledge. Second, my business objects often don't obtain their from the data portal but are obtained from another web service. In those cases, we are delegating to a service proxy to obtain the data and transforming it into our business object/list - no data portal involved.
My thoughts are to implement a more generic approach for the CslaDataProvider that will allow us to abstract the DataPortal, decoupling the dependancy and allow us to choose if and when the data portal is being used in our applications.
The data provider model actually is an event model. The "callback" methods are really event handlers, but with lambda expressions nobody seems to actually hook these up as "events" anymore. But if you really want the eventing model, it is there.
Your point about the argument parameter types being tied to the data portal is valid though. I find it irritating as well. We chose to go that route as a minor performance optimizaiton. If the data provider uses its own argument type, then the data provider needs to do a mapping operation to get the data portal's async argument, and copy the values into the data provider async argument.
It may be worth doing that - though it would be a breaking change to all existing code that uses the data provider...
The thing is, I'm not sure the data provider model as a future. The data provider concept was introduced with WPF and appeared to be the primary direction Microsoft was going in terms of data access in XAML. Then Silverlight shows up with no data provider concept at all. And now very few people talk about the data provider on the WPF side either - favoring the more complex MVVM ideas.
As you are probably aware, I'm experimenting with some MVVM concepts for version 3.8, and I rather expect that people will migrate away from the data provider toward the view model concept - due to peer pressure if nothing else.
Still, I'll add this to the wish list - but given that it would break nearly every app out there it is a hard pill to swallow...
So the thought would be that the View would replace the data provider and expose the ViewModel to the UI for data binding? Would the View be set as the DataContext or the ViewModel? If the former, wouldn't the current CslaDataProvider essentially become a base class for the Views?
Are you planning any more posts on MVVM in the near future? I am very interested in what you are learning and able to accomplish (and how!).
I just got back from a week's vacation, so I haven't done anything for a while :)
The MVVM pattern says you have a View (your XAML and code-behind), a Model (your business object) and a ViewModel (an intermediary the greases the wheels for interaction between the View and the Model).
Exactly how and what a ViewModel is varies quite a lot depending on who you talk to. Since CSLA business objects are a rich Model (as opposed to an anemic Model like a DTO or entity object), the ViewModel exposes the Model as a property, and also exposes "verbs" (methods) and extra properties for use by the View.
The end result is that the ViewModel is much like a data provider - in that it exposes the business object as a property, along with some other properties and methods. But in WPF it won't be constricted by the data provider base class - and in fact I'm implementing the ViewModel<T> base class as a dependency object (a FrameworkElement in Silverlight) so it is fully bindable.
At a high level you can use a VM much like a data provider, but they are potentially more flexible in SL and are absolutely more flexible in WPF.
The View binds to the VM (and the Model). The VM interacts with the Model to implement its extra properties and methods.
In my mind, through a combination of controls and the VM, the View would have no code-behind at all, except maybe for eye-candy stuff dealing with animations or other pure designer-type stuff.
All the "real" functionality is handled entirely through binding - either binding UI control properties directly to VM or M properties, or having more powerful UI controls (like PropertyStatus) that provide rich, but abstract, interaction with the M.
My goal is unchanged - you should be able to create nearly any CRUD screen without writing any code in the View (and preferably none in the ViewModel) outside of any eye candy stuff you want to add.
Copyright (c) Marimer LLC