RE: Request for new DataProvider events

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

 

 

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?