Request for new DataProvider events

Request for new DataProvider events

Old forum URL: forums.lhotka.net/forums/t/7204.aspx

Jack posted on Tuesday, June 30, 2009

Rocky,

I'm using the DataProvider as a property in a ViewModel and has replicated a number of the CanXXX properties.  Would it be possible to get an event for each of RefreshCanOperationsValues and RefreshCanOperationsOnObjectLevel to indicate that those methods have fired? 

I'd like to trigger a PropertyChanged event for all my related  CanXXX in one go vs. trapping and mapping each firing of  the CSLADataProvider.PropertyChanged event. 

Currently I'm looking for Properties where the name StartsWith("Can") and just replicating the call but I would like to know on a global level.

Thanks

jack

RockfordLhotka replied on Tuesday, June 30, 2009

This is why I think the MVVM pattern is kind of silly - at least when you have something other than an anemic Model.

You are writing all that code in your VM to replicate functionality that already exists in the Model and/or the data provider. Doesn't that seem really silly to you? It does to me.

I really think the long-term answer is probably to create a ViewModelBase class in CSLA .NET so you can inherit from it to get a VM that already does all the basic stuff that the CslaDataProvider does for you.

In other words, I don't think I'll be bastardizing the data provider model to fit the MVVM pattern, because they are different things. I think the correct answer is to provide direct support for the MVVM pattern - at least the variant of the pattern than is reasonably sane for dealing with a rich Model like one you get when creating CSLA .NET objects.

And I'm sure I'll make some people unhappy in so doing, because they'll want to use one of the MVVM variants designed for anemic Models with CSLA .NET - but I'm OK with that, because to me that's just silly :)

Sorry for the rant - just had to get that out of my system.

Seriously - I think you should consider ripping the code out of CslaDataProvider and creating your own ViewModelBase class that already implements all the Can___() methods and so forth. You are going to want those on every VM anyway, so why write that code over and over and over again?

Jack replied on Tuesday, June 30, 2009

Rocky,

Well there are worse things than being silly :-) but I do hear and understand your point.  Its also very hard to get a grasp of all the different ideas and methodologies and acronyms etc out there and come up with a simple concept that meets ones needs.  Especially if you want to combine ideas and frameworks from multiple sources.

I actually have a base class that implements most of the CanXyz in a MyAppModelBase but then I extended it to be a MyAppCslaModelBase where it pulled in the CSLADataProvider as a property for the scenarios (many) where I want to use a the data provider to do much of the work.  I have an ICslaModel interface that I just use to ensure I map the work you've already done and make sure I implement what I need.

Then I've taken some of the properties (such as IsBusy) and modified it to do

                get{ return _isBusy || _cslaDataProvider.IsBusy;}

other just stay the same

                public bool CanCancel {return _cslaDataProvider.CanCancel;}

So my ViewModel is a hybrid of whatever I choose / need.  I'm actually pretty happy with it.  What I think would be most useful would be a CSLA managed interface that I can include to ensure that whatever CanXyz or (silly MVVM Base implementations) I also pick up.  That keeps me confident I am working from the same starting point as you/CSLA.

So if the CslaDataProvider could implement ISillyViewModel then I could also and never have to worry that I miss a modification or good idea that CSLA implements.

ISillyViewModel for me is the CanXyz's.

It took me longer to write these two posts than it did to cut/paste and replicate the properties I cared about so to me it wasn't a waste of effort.

Thanks

jack

RockfordLhotka replied on Wednesday, July 01, 2009

Jack:
Rocky,

Well there are worse things than being silly :-) but I do hear and understand your point. 

I meant no offense. I've just observed that patterns come and go like fads, and the MVVC pattern is the current "pattern of the day". It is too young (imo) to know if it is actually any good, but a lot of people are experimenting with it, so in a couple years I'm sure we'll know whether it actually provides good value - and if so, how.

I'm just not sure that the CslaDataProvider has any place in an MVVM scenario. I can see where some of the functionality in the data provider would have value in a VM, but perhaps not the data provider itself.

The data provider model is something WPF introduced when it came out. The purpose of the data provider is to allow a XAML designer/developer to access data and use data binding without writing any code behind the form.

The MVVM pattern has you writing code "behind the form" in a VM. So already we see that this departs from the data provider model of "no code".

I know, what I'm saying here is heresy - implying that the VM is "code behind" - but it is. Unless you write a VM that can be used behind multiple forms, all you are doing is writing code-behind, but in a more complex manner than you need to.

My goal in enhancing and extending the data provider model was to take the "no code behind" concept and carry it as far as possible, so you could at least create basic data view/entry screens without writing any code in the UI layer - just pure XAML.

I still think that's a good goal. I think most forms should not require a manually-created VM class. That's just code in the UI, and code in the UI is bad.

I do appreciate that some forms are so complex that they will require code in the UI. And I understand people not wanting to use the actual code-behind model because it feels like VB3. But if a VM class just contains code that would have been in the code-behind, then that's silly, because it is just a developer doing extra work to pretend to solve a problem - when all they've really done is added unnecessary complication to arrive at the same place.

To put it another way, I think that any code written in the UI (in an ideal world) would be written in XAML controls or attached properties, so that code is leveraged (or not) entirely by the XAML designer/developer.

Not that I do that either - because it is harder. But it is better, because it shifts the control to the XAML and provides better decoupling.

And ultimately coupling is the issue. If your VM is tightly coupled to your V, then the VM is just a complicated version of code-behind, and so it seems to me that you have all the negatives of code-behind PLUS all the negatives of extra complexity. A total lose-lose scenario.

Jack replied on Wednesday, July 01, 2009

Rocky,

 

No offense taken at all - I was just being cheeky.

 

As you clearly point out I am purely after the functionality and leveraging your efforts and won't pretend to be able to speak to the correct use of various patterns etc.  With respect to Silverlight everything is so young that I'm finding myself just trying to stick to a few standards and I'll see what happens.  I'm sure version 2.0 of my application under CSLA 4.x and Silverlight x will look completely different and I'll be far wiser.  Hopefully I get paid to do all the rework :-).

 

If you feel that it is a better approach to expose the functionality of the DataProvider for re-use so that one doesn't actually add a data provider then please consider adding that as an enhancement.

 

I think it would be helpful to the community if it is easier to re-use and implement your logic vs. re-writing.  I fully agree that you shouldn't start basterdising CSLA to support fad's and I especially will heed your warnings.

 

thanks

 

jack

 

From: RockfordLhotka [mailto:cslanet@lhotka.net]
Sent: July-01-09 9:07 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] Request for new DataProvider events

 

Jack:

Rocky,

Well there are worse things than being silly :-) but I do hear and understand your point. 

I meant no offense. I've just observed that patterns come and go like fads, and the MVVC pattern is the current "pattern of the day". It is too young (imo) to know if it is actually any good, but a lot of people are experimenting with it, so in a couple years I'm sure we'll know whether it actually provides good value - and if so, how.

I'm just not sure that the CslaDataProvider has any place in an MVVM scenario. I can see where some of the functionality in the data provider would have value in a VM, but perhaps not the data provider itself.

The data provider model is something WPF introduced when it came out. The purpose of the data provider is to allow a XAML designer/developer to access data and use data binding without writing any code behind the form.

The MVVM pattern has you writing code "behind the form" in a VM. So already we see that this departs from the data provider model of "no code".

I know, what I'm saying here is heresy - implying that the VM is "code behind" - but it is. Unless you write a VM that can be used behind multiple forms, all you are doing is writing code-behind, but in a more complex manner than you need to.

My goal in enhancing and extending the data provider model was to take the "no code behind" concept and carry it as far as possible, so you could at least create basic data view/entry screens without writing any code in the UI layer - just pure XAML.

I still think that's a good goal. I think most forms should not require a manually-created VM class. That's just code in the UI, and code in the UI is bad.

I do appreciate that some forms are so complex that they will require code in the UI. And I understand people not wanting to use the actual code-behind model because it feels like VB3. But if a VM class just contains code that would have been in the code-behind, then that's silly, because it is just a developer doing extra work to pretend to solve a problem - when all they've really done is added unnecessary complication to arrive at the same place.

To put it another way, I think that any code written in the UI (in an ideal world) would be written in XAML controls or attached properties, so that code is leveraged (or not) entirely by the XAML designer/developer.

Not that I do that either - because it is harder. But it is better, because it shifts the control to the XAML and provides better decoupling.

And ultimately coupling is the issue. If your VM is tightly coupled to your V, then the VM is just a complicated version of code-behind, and so it seems to me that you have all the negatives of code-behind PLUS all the negatives of extra complexity. A total lose-lose scenario.



Copyright (c) Marimer LLC