Here are some of my thoughts on these matters ... a condensation of my separate communications with alindzon ... reprised here for the DevForce audience.
I'm alergic to the RIA Services Domain Data Source (DDS) and all similar attempts to inscribe business logic in the XAML. Such logic doesn't belong there. When it's in the view, the view becomes an untestable, unmaintainable mess. I'm not saying this because it's fashionable to opine about "Separation of Concerns". I'm saying it from ugly experience trying to make sense of customer application mud balls.
The DDS is a terrible idea. I respect and like the people who wrote it. They know how I feel. I believe they agree with me. But their masters at Microsoft don't believe you are good enough or smart enough to write decent code. As the saying goes, no one ever went broke underestimating the intelligence of the masses.
Of course they are right in a way. If you keep dazzlling folks with single screen demos. If you consistently misguide them with bad practices. Sure ... they'll fall for it. And then you can say "we gave them what they wanted." No you didn't. You taught them to want the wrong thing.
Am I disgusted by it? Yes I am.
Our IdeaBlade hearts aren't that pure either. If we can't beat 'em, we might as well join them. Because you're now trained to want this crap, we'd like to show you how to tie your DevForce EntityManager into the DDS.
Unfortunately, Microsoft made sure we can't; the DDS UI control only works with RIA Services' Data Context. So (drum roll, please) we offer you our own look-alike, the IdeaBlade.Windows.SL.ObjectDataSource. Give it a try if you want to roll this way. It's based on the pre-release version of the DDS ... the design for RIA Services in Silverlight 3. The API has changed. Our ODS hasn't nor does it support the ability to run the search as you type. We'll bring it up-to-date eventually.
On the other hand, if you want my advice ... avoid it. Don't use the DDS. Don't use our ODS. Follow the View-ViewModel pattern ... which is not hard at all ... and spare yourself some future pain. You'll thank me later.
The fact is that you can easily do what the DDS does with simple code following the View-ViewModel pattern. Much has been said about MVVM. It boils down to this: the View's job is to look good; the ViewModel's job is to do the work; binding brings them together.
In this context it means that the UI controls for gathering the user's criteria ... the Company and Contact to search ... those controls go in the view. The logic to incorporate the user's criteria values into a query and run that query ... such logic belongs in the ViewModel.
You will bind the FilterCompany TextBox to the ViewModel ... just as you would any other data value. Let the binding push the search text into the ViewModel which senses the change, constructs the query, and executes it.
Ok .. it's not drag-and-drop. But you get code you can understand, debug, and test. If you need more features, you can add them. It's not a black box ... like the DDS ... where the minute you stray from the ordinary you're stuck. A black box is ok if it does something hard. This stuff is easy.
I already confessed that DevForce does not ship with a mechanism to watch your keystrokes and run the filter query automatically as you type.
Although you could write this yourself, you'd rather we took a crack at it first. So we will. And we'll give you the source. Then you can take it, or leave it, or do what you want with it.
We haven't written it yet. I've been thinking about how it might work, using alindzon's request as a guide.
1. Your TextBox is bound to the ViewModel.FilterCompany property via an attached property or "behavior" (TBD).
2. Your ViewModel has a method, “FilterFoo()”, that performs the filtered query; the method code might look like
var query = Manager.Foo
// your grid’s ItemSource is bound to ResultList
3. “FilterFoo” was mentioned when you attached the TextBox property.
How bad would that be? Is this harder than RIA Services? To my eye it’s both simple and transparent.
The Behavior would be pretty simple. It listens for keystrokes. When the key stroking “stops” (i.e., there have been no new keystrokes after the prescribed delay), it invokes your FilterFoo(). The only trickiness is aggregating key stroke across the several controls that participate in the filtering (e.g., FilterCompany and FilterContact textboxes). You get that when you associate each TextBox with the ViewModel filtering method.
AddFilter (TBD) is an extension method on IQueryable<T> that constructs the Where clause(s). It knows to skip the clause if FilterCompany is empty after trimming. You could add the Ignore list as a third parameter if you needed it.
This is DevForce as you know it. And you can use the Behavior anywhere. When you figure out how to trick out your grid with filter input controls, just attach the Behavior to it.
Dear reader ... let me know what you think.