What about if you and our WPF/Silverlight community create a standard for MVVM pattern? I understand that there are a lot of way to implement MVVM but at least, there are some obvious rules that everyone can follow so everyone has same understanding about that pattern.
Here are some of my thoughts.
*Goals*
- - Testabiltiy ( ViewModel is easier to unit test than code-behind or event driven code) - Clear seperation between UX designer and developer - Increases the "Blendability" of your view - Model never needs to be changed to support changes to the view - ViewModel rarely needs to be changed to support changes to the view - No duplicated code to update views
*Do and Don't in View*
- *shouldn't contain any logic that you want to test* : As Glenn said that MVVM is not code counting exercise, we can write code in code-behind. But you should never write any logic that you want to test. For example: If user select a country then you want to display the list of states or city in your view. This is the business requirement so you should have unit test to test this logic. So, you shouldn't write it in code-behind. - *can be a user control or Data Template* - *Keep the view as simple as possible. : *We can still use Data Trigger or Value Converter or Visual State or Blend Behivor in XAML with care. - *use attached property if something is not bindable : *There is one common mistake about PasswordBox. We all knows that WPF Password is not bindable due to the security reason. But if you are having a string property "Password" in Model then it won't be secure no matter whether you set it from code-behind or attached property.
*Do and Don't in ViewModel*
- An abstraction of View - Connector between View and Model - Keep View State, Value Conversion - No strong or weak (via Interface) reference of View - Make VM as testable as possible (e.g. no call to Singleton class) - No Control related Stuff in VM ( Because if you are changing the view then you will have to change VM as well. )
*Model *
- - can be Data Model, DTO, POCO, auto-generated proxy of domain class and UI Model based on how you want to have the separation between Domain Service and Presentation Layer - No reference to ViewModel
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com> wrote:
> On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> wrote:
>> Hi John,
>> Thanks for creating MVVM pattern. :)
> To be clear...I didn't actually create it, I learned it from some Smalltalk > devs and figured out how to use it with WPF...but you're welcome. :-)
>> >>1) efficiently write rich UI
>> I agree that we can use MVVM to write rich UI efficiently. But I don't >> think that MVVM is the only way to write rich UI efficiently. There are a >> lot of patterns that we can write rich UI ( UI is not just WPF/Silverlight)
> I didn't say it was the only way. All I said was one of the goals of MVVM > was to write UI efficiently.
>> >>2) where the code is maintainable
>> The same goes for this as well. Writing maintainable code is not just >> about MVVM.
>> >>3) the model never needs to be changed to support changes to the view >> >>4) the viewmodel rarely if ever needs to be changed to support changes >> to the view >> >>5) there can be many views of the same viewmodel
>> Agreed.
>> >>6) the design is as toolable as possible.
>> Do you agree the fact that we need to dump the view as much as possible?
> If by "dump" you mean write as little code as possible in the view, I don't > think that is a goal. It *may* be part of the solution, but I think the > real thing is to only have code in the view that actually has to do with the > view. Animation code may be huge, but as long as it doesn't include > business logic it is fine in the view.
>> Do you think that using Data Trigger or Value Converter are anti-MVVM? If >> yes then what about using Visual State Manager, Blend Behivor, Event or >> Property Trigger?
> On the contrary, all those things were created to support the MVVM > pattern.
>> Is it okay to have control-related stuffs (like Control Event or etc ) in >> View Model?
> No. Then you can't switch what Control (a view thing) you use without > modifying the ViewModel.
>> I'd love to hear other's opinion as well for those questions.....
>> Regards, >> Michael Sync
>> Don't go the way life takes you. >> Take life the way you go
>> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman <gossmans...@gmail.com>wrote:
>>> I haven't written anything about MVVM in a while because there is so much >>> material already being published. However I have been thinking about what >>> we can do in the platform to make things better and reading a lot of the >>> public stuff, so I thought I'd summarize for my own sake if nothing else:
>>> The state of MVVM reminds me of Peter Naur's classic paper "Programming >>> as Theory Building". He basically says the proper model for computer >>> programming is not engineering but scientific development where you have >>> problem, you develop a hypothesis for how to fix it, you experiment (write >>> code and test it), and then you decide whether you've solved the problem. >>> If not you synthesize a new hypothesis and try again.
>>> MVVM feels more like "science" than anything else I've seen...with lots >>> of authors publishing papers containing their hypotheses and results and >>> suggesting avenues for further research. Some papers are better than >>> others, some are revolutionary and some contain nothing new.
>>> Fundamentally I think the goal of MVVM has still not been clearly >>> stated. I posit some of the goals include: >>> 1) efficiently write rich UI >>> 2) where the code is maintainable >>> 3) the model never needs to be changed to support changes to the view >>> 4) the viewmodel rarely if ever needs to be changed to support changes to >>> the view >>> 5) there can be many views of the same viewmodel >>> 6) the design is as toolable as possible.
>>> To my mind #6 is the most important and perhaps the one we still have >>> made the least progress with. Blend Behaviors are a huge step in the right >>> direction, but we need to go further.
>>> I don't think eliminating all code from the View is part of the goal, >>> though it obviously makes some of the others easier. When it makes them >>> harder though, one should write view code (though whether that means the >>> code behind model or something else is not clear).
>>> Among the next steps, I would like to eliminate the boilerplate code for >>> INotifyPropertyChanged (and eventually eliminate DependencyProperties and >>> DependencyObjects and allow any property on any class to support binding and >>> change notification). Further I would like to bind events in the View >>> directly to Commands on the ViewModel so you can say <Button Click="{Binding >>> SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This >>> leads to the question whether ICommand itself is just boilerplate and we can >>> simply remove it with binding directly to methods. The downside being it >>> isn't clear all methods can/should be called from the View in which case it >>> may be useful to have contract (currently offered by the list of properties >>> of type ICommand). On the tooling side I would like to see a UI where you >>> can select a control, see a list of the events it supports and choose which >>> methods on the ViewModel you want them to trigger. This leads in turn to >>> how to handle event arguments like keys. Keybinding is already pretty good, >>> but the syntax should be simple.
On Wed, Feb 3, 2010 at 11:38 AM, Michael Sync <mchls...@gmail.com> wrote: > Do and Don't in View
> shouldn't contain any logic that you want to test : As Glenn said that MVVM > is not code counting exercise, we can write code in code-behind. But you > should never write any logic that you want to test. For example: If user > select a country then you want to display the list of states or city in your > view. This is the business requirement so you should have unit test to test > this logic. So, you shouldn't write it in code-behind.
This is a wonderful description of the requirement. Fully on board. From a personal POV, I like to go a little further, not for a developer/architectural reason, but because I want the View to be as nearly entirely in the realm of the designer as possible, and the designer shouldn't be writing code. But that's not really a goal/requirement of MVVM.
> can be a user control or Data Template
Or custom control ;). Sorry, I know you meant this, but saying "user control" instead of just "control" rubbed me wrong.
> Keep the view as simple as possible. : We can still use Data Trigger or > Value Converter or Visual State or Blend Behivor in XAML with care.
I'm not sure I understand this. It doesn't seem to be related to MVVM and I don't know what you mean by "with care".
> use attached property if something is not bindable : There is one common > mistake about PasswordBox. We all knows that WPF Password is not bindable > due to the security reason. But if you are having a string property > "Password" in Model then it won't be secure no matter whether you set it > from code-behind or attached property.
This seems like an implementation detail and not a goal/requirement. Also, while I don't really understand why PasswordBox's design makes it "secure", I can't agree that having a property in the Model makes anything insecure. Your model could just as easily use a SecureString making it "secure". Then all that's in question is how you move the password from the PasswordBox to the Model in a secure fashion, and that can certainly be accomplished in various ways, such as using a service. Heck, it could probably even be done using the attached behavior approach. I'd suggest you drop this from the list.
> Do and Don't in ViewModel
> An abstraction of View
That's the definition of the pattern, right? Not sure you need to call it out in a do/don't list.
> Connector between View and Model
Possible between View and Models.
> Keep View State, Value Conversion
Value conversion need not go in the ViewModel, so you should be careful in how this is worded.
> No strong or weak (via Interface) reference of View
I simply can't agree with this. At all. There's no benefit in forcing this, and in fact there's a lot of benefits in maintaining a "weak reference" (wrong term, but it's what you used) to the View.
> Make VM as testable as possible (e.g. no call to Singleton class)
The Singleton pattern must die! If for no other reason than the confusion it brings to discussions like this. IoC containers have the concept of a singleton, but they are obtained through dependency injection instead of through calls to static methods. That's what you really meant by Singleton here, is you shouldn't have a dependency on static methods/properties.
> No Control related Stuff in VM ( Because if you are changing the view then > you will have to change VM as well. )
Depends on what you mean by "control related". You absolutely should not have any hard dependencies on a control, but looser dependencies may be necessary. For instance, being able to change the focus may be a necessary part of the "business logic" of the View, and you'll need to be able to do that in the ViewModel. There's ways to do this in an abstract fashion that does not create hard dependencies between the ViewModel and any particular View. This is fine. Kind of like with the "no reference to the View" item above, it's really only important that you need create hard dependencies.
> Model
> can be Data Model, DTO, POCO, auto-generated proxy of domain class and UI > Model based on how you want to have the separation between Domain Service > and Presentation Layer > No reference to ViewModel
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
Testability is one of the goals of MVVM, right? So, having business logic in View is not good idea. So, I was suggesting that we should not put any logic that we want to test in codebehind.
>>control" instead of just "control" rubbed me wrong.
Yeah. Thanks. :)
>>I'm not sure I understand this. It doesn't seem to be related to MVVM and
I don't know what you mean by "with care".
We used to argue that using Data Trigger in View is not good idea because it allows us to write the logic in View.
>>I'm not sure I understand this. It doesn't seem to be related to MVVM >>Value conversion need not go in the ViewModel, so you should be careful in
how this is worded.
Im refering Justin's Value Converter Code smell. Let's say you want to show the Country Name. But you have only Country ID in VM so you will use VC to converter ID to Name. The suggestion is that if we like to show the name then just add it in VM instead of using Converter.
>>>while I don't really understand why PasswordBox's design makes it
"secure"
According to WPF team, they don't make Passwod bindable for Security. There are a few discussion about that in WPF forum.
>> I can't agree that having a property in the Model makes anything insecure
Some people think that using attached property for Password is insecure and they think that you should set it in codebehind. My point is that it doesn't matter whether you use the attached property to bind the model or set it manually from codebehind. As long as the property of Password is a string then it will not be secure anyway.
Yes. You are right. We should use SecureString in Model and we can even use SecureString in attached property. yeah.. It should not be in the list.
>>> Not sure you need to callit out in a do/don't list.
Yes. Agreed.
>>I simply can't agree with this. At all. There's no benefit in
forcing this, and
>>in fact there's a lot of benefits in maintaining a "weak reference" (wrong
term, but it's what you used) to the View.
I dont think it's wrong term. What I meant by "weak" is not .NET WeakReference. I saw people using it like that in forum. Anyway, I'm not a native English speaker so you can suggest me what I should call that one.
Could you please give me some example of having IVew in VM? Would it be like MVP pattern?
Thanks for your inputs. I really appreciate it... I think that it will help us to understand more about MVVM and we can have same understanding as well.. Otherwise, people will say that My "MVVM" is totally different from your MVVM.. :)
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
On Thu, Feb 4, 2010 at 1:15 AM, Bill Kempf <weke...@gmail.com> wrote: > On Wed, Feb 3, 2010 at 11:38 AM, Michael Sync <mchls...@gmail.com> wrote: > > Do and Don't in View
> > shouldn't contain any logic that you want to test : As Glenn said that > MVVM > > is not code counting exercise, we can write code in code-behind. But you > > should never write any logic that you want to test. For example: If user > > select a country then you want to display the list of states or city in > your > > view. This is the business requirement so you should have unit test to > test > > this logic. So, you shouldn't write it in code-behind.
> This is a wonderful description of the requirement. Fully on board. > From a personal POV, I like to go a little further, not for a > developer/architectural reason, but because I want the View to be as > nearly entirely in the realm of the designer as possible, and the > designer shouldn't be writing code. But that's not really a > goal/requirement of MVVM.
> > can be a user control or Data Template
> Or custom control ;). Sorry, I know you meant this, but saying "user > control" instead of just "control" rubbed me wrong.
> > Keep the view as simple as possible. : We can still use Data Trigger or > > Value Converter or Visual State or Blend Behivor in XAML with care.
> I'm not sure I understand this. It doesn't seem to be related to MVVM > and I don't know what you mean by "with care".
> > use attached property if something is not bindable : There is one common > > mistake about PasswordBox. We all knows that WPF Password is not bindable > > due to the security reason. But if you are having a string property > > "Password" in Model then it won't be secure no matter whether you set it > > from code-behind or attached property.
> This seems like an implementation detail and not a goal/requirement. > Also, while I don't really understand why PasswordBox's design makes > it "secure", I can't agree that having a property in the Model makes > anything insecure. Your model could just as easily use a SecureString > making it "secure". Then all that's in question is how you move the > password from the PasswordBox to the Model in a secure fashion, and > that can certainly be accomplished in various ways, such as using a > service. Heck, it could probably even be done using the attached > behavior approach. I'd suggest you drop this from the list.
> > Do and Don't in ViewModel
> > An abstraction of View
> That's the definition of the pattern, right? Not sure you need to call > it out in a do/don't list.
> > Connector between View and Model
> Possible between View and Models.
> > Keep View State, Value Conversion
> Value conversion need not go in the ViewModel, so you should be > careful in how this is worded.
> > No strong or weak (via Interface) reference of View
> I simply can't agree with this. At all. There's no benefit in forcing > this, and in fact there's a lot of benefits in maintaining a "weak > reference" (wrong term, but it's what you used) to the View.
> > Make VM as testable as possible (e.g. no call to Singleton class)
> The Singleton pattern must die! If for no other reason than the > confusion it brings to discussions like this. IoC containers have the > concept of a singleton, but they are obtained through dependency > injection instead of through calls to static methods. That's what you > really meant by Singleton here, is you shouldn't have a dependency on > static methods/properties.
> > No Control related Stuff in VM ( Because if you are changing the view > then > > you will have to change VM as well. )
> Depends on what you mean by "control related". You absolutely should > not have any hard dependencies on a control, but looser dependencies > may be necessary. For instance, being able to change the focus may be > a necessary part of the "business logic" of the View, and you'll need > to be able to do that in the ViewModel. There's ways to do this in an > abstract fashion that does not create hard dependencies between the > ViewModel and any particular View. This is fine. Kind of like with the > "no reference to the View" item above, it's really only important that > you need create hard dependencies.
> > Model
> > can be Data Model, DTO, POCO, auto-generated proxy of domain class and UI > > Model based on how you want to have the separation between Domain Service > > and Presentation Layer > > No reference to ViewModel
> -- > Quidquid latine dictum sit, altum sonatur. > - Whatever is said in Latin sounds profound.
> War is peace. Freedom is slavery. Bugs are features.
On Wed, Feb 3, 2010 at 12:55 PM, Michael Sync <mchls...@gmail.com> wrote: > Thanks, Bill. >>> that's not really a goal/requirement of MVVM. > Testability is one of the goals of MVVM, right? So, having business logic in > View is not good idea. So, I was suggesting that we should not put any logic > that we want to test in codebehind.
That's taken out of context, and you misunderstood me. "That's not really a goal/requirement of MVVM" wasn't in reference to your stated goal, but to my extended goal of eliminating code behind for the sake of less designer friction.
>>>I'm not sure I understand this. It doesn't seem to be related to MVVM and >>> I don't know what you mean by "with care". > We used to argue that using Data Trigger in View is not good idea because it > allows us to write the logic in View.
That sort of argument always bothers me. When something "allows you" to do something, it's not the same as requiring or even encouraging you to do it. The bad idea is putting business logic in the View, and I can write plenty of data triggers that don't do that.
>>>I'm not sure I understand this. It doesn't seem to be related to MVVM >>>Value conversion need not go in the ViewModel, so you should be careful in >>> how this is worded. > Im refering Justin's Value Converter Code smell. Let's say you want to show > the Country Name. But you have only Country ID in VM so you will use VC to > converter ID to Name. The suggestion is that if we like to show the name > then just add it in VM instead of using Converter.
Yeah, and that idea is controversial. Me, I'd rather use a converter if this is going to be done frequently. Does a much better job of keeping things DRY this way. More importantly, there's a lot of value converters that simply do NOT belong in the ViewModel, ever. Things like a SeverityToColorConverter come to mind. This is solely a presentation concept, and has no place in a ViewModel.
>>>I simply can't agree with this. At all. There's no benefit in >>> forcing this, and >>>in fact there's a lot of benefits in maintaining a "weak reference" (wrong >>> term, but it's what you used) to the View. > I dont think it's wrong term. What I meant by "weak" is not .NET > WeakReference. I saw people using it like that in forum. Anyway, I'm not a > native English speaker so you can suggest me what I should call that one.
Abstract is probably better than weak. And coupling is better than reference. They mean the same thing in some contexts, but in .NET languages a reference has a specific meaning, so "weak reference" can confuse people.
> Could you please give me some example of having IVew in VM? Would it be like > MVP pattern?
Onyx is heavily based on an IView concept, so you could look there. At runtime, there's a logical coupling betwen a View and a ViewModel, and not maintaining a physical reference between them can thus lead to complications. For instance, if you take a ViewModel first approach, you have to be careful to maintain a reference to the View somehow, lest the GC collect the View prematurely.
> Thanks for your inputs. I really appreciate it... I think that it will help > us to understand more about MVVM and we can have same understanding as > well.. Otherwise, people will say that My "MVVM" is totally different from > your MVVM.. :)
To some extent, that's a good thing. MVVM is a pattern. Patterns can be applied in multiple ways. As long as the pattern is still adhered to, the differing applications are not really relevant. Things like "not having any reference to the View from the ViewModel" are not part of the pattern.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
>>Abstract is probably better than weak. And coupling is better
than reference. They mean the same thing in some contexts, but in .NET languages a reference has a specific meaning, so "weak reference" can confuse people.
Thanks, Bill. I will use "Abstract Coupling" instead of "Weak reference (via interface)" in future.
>>Things like a SeverityToColorConverter come to mind. This is solely
a presentation concept, and has no place in a ViewModel.
Yeah. I totally agreed with this.
>>I can write plenty of data triggers that don't do that
That's why I wanted to say that we can use Data Triggers or Value Converter in View. But we need to be careful not to write the business logic with Data Trigger. Yes. I have seen that people use Data Trigger for some business logic.
>>Onyx is heavily based on an IView concept, so you could look there
Sure. I'm planning to take a look at all MVVM frameworks.
Please help me to take a look at the code below. Is it MVP or MVVM?
interface IView{
void ShowMessage(string message);
}
class View : IView { public void ShowMessage(string message){ MessageBox.Show(this, message); }
}
class ViewModel{
private IView view;
public ViewModel(IVew view){
this.view = view;
}
........
view.ShowMessage("This is a msg");
} >>>To some extent, that's a good thing. MVVM is a pattern. Patterns can be
applied in multiple ways. As long as the pattern is still adhered to, the differing applications are not really relevant. Things like "not having any reference to the View from the ViewModel" are not part of the pattern.
This is what you believe, right? There are a lot of people who believe that VM should not have any view reference. According to John's class diagram < link <http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx>>, the 2-ways binding is the only way that we communicate between View and ViewModel. Not via interface.
I believe that "not having any reference to the View from the ViewModel" can be a part of pattern because we don't want VM to be changed to support the changes of View.
Actually, pattern has a name. The way of implementing the pattern can be different and we can combine a few patterns together based on our need. But still it has a name.
Regards, Michael Sync
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
On Thu, Feb 4, 2010 at 2:29 AM, Bill Kempf <weke...@gmail.com> wrote: > On Wed, Feb 3, 2010 at 12:55 PM, Michael Sync <mchls...@gmail.com> wrote: > > Thanks, Bill. > >>> that's not really a goal/requirement of MVVM. > > Testability is one of the goals of MVVM, right? So, having business logic > in > > View is not good idea. So, I was suggesting that we should not put any > logic > > that we want to test in codebehind.
> That's taken out of context, and you misunderstood me. "That's not > really a goal/requirement of MVVM" wasn't in reference to your stated > goal, but to my extended goal of eliminating code behind for the sake > of less designer friction.
> >>>I'm not sure I understand this. It doesn't seem to be related to > MVVM and > >>> I don't know what you mean by "with care". > > We used to argue that using Data Trigger in View is not good idea because > it > > allows us to write the logic in View.
> That sort of argument always bothers me. When something "allows you" > to do something, it's not the same as requiring or even encouraging > you to do it. The bad idea is putting business logic in the View, and > I can write plenty of data triggers that don't do that.
> >>>I'm not sure I understand this. It doesn't seem to be related to MVVM > >>>Value conversion need not go in the ViewModel, so you should be careful > in > >>> how this is worded. > > Im refering Justin's Value Converter Code smell. Let's say you want to > show > > the Country Name. But you have only Country ID in VM so you will use VC > to > > converter ID to Name. The suggestion is that if we like to show the name > > then just add it in VM instead of using Converter.
> Yeah, and that idea is controversial. Me, I'd rather use a converter > if this is going to be done frequently. Does a much better job of > keeping things DRY this way. More importantly, there's a lot of value > converters that simply do NOT belong in the ViewModel, ever. Things > like a SeverityToColorConverter come to mind. This is solely a > presentation concept, and has no place in a ViewModel.
> >>>I simply can't agree with this. At all. There's no benefit in > >>> forcing this, and > >>>in fact there's a lot of benefits in maintaining a "weak reference" > (wrong > >>> term, but it's what you used) to the View. > > I dont think it's wrong term. What I meant by "weak" is not .NET > > WeakReference. I saw people using it like that in forum. Anyway, I'm not > a > > native English speaker so you can suggest me what I should call that one.
> Abstract is probably better than weak. And coupling is better than > reference. They mean the same thing in some contexts, but in .NET > languages a reference has a specific meaning, so "weak reference" can > confuse people.
> > Could you please give me some example of having IVew in VM? Would it be > like > > MVP pattern?
> Onyx is heavily based on an IView concept, so you could look there. At > runtime, there's a logical coupling betwen a View and a ViewModel, and > not maintaining a physical reference between them can thus lead to > complications. For instance, if you take a ViewModel first approach, > you have to be careful to maintain a reference to the View somehow, > lest the GC collect the View prematurely.
> > Thanks for your inputs. I really appreciate it... I think that it will > help > > us to understand more about MVVM and we can have same understanding as > > well.. Otherwise, people will say that My "MVVM" is totally different > from > > your MVVM.. :)
> To some extent, that's a good thing. MVVM is a pattern. Patterns can > be applied in multiple ways. As long as the pattern is still adhered > to, the differing applications are not really relevant. Things like > "not having any reference to the View from the ViewModel" are not part > of the pattern.
> -- > Quidquid latine dictum sit, altum sonatur. > - Whatever is said in Latin sounds profound.
> War is peace. Freedom is slavery. Bugs are features.
On Wed, Feb 3, 2010 at 9:51 PM, Michael Sync <mchls...@gmail.com> wrote: > Please help me to take a look at the code below. Is it MVP or MVVM?
> interface IView{
> void ShowMessage(string message);
> }
> class View : IView {
> public void ShowMessage(string message){
> MessageBox.Show(this, message);
> }
> }
> class ViewModel{
> private IView view;
> public ViewModel(IVew view){
> this.view = view;
> }
> ........
> view.ShowMessage("This is a msg");
> }
There's not enough info here to say for sure. It could go either way. I will say, however, that this is not what I would do. Onyx has an IDisplayMessage service for this.
>>>>To some extent, that's a good thing. MVVM is a pattern. Patterns can be >>>> applied in multiple ways. As long as the pattern is still adhered to, the >>>> differing applications are not really relevant. Things like "not having any >>>> reference to the View from the ViewModel" are not part of the pattern. > This is what you believe, right? There are a lot of people who believe that > VM should not have any view reference. According to John's class diagram > <link>, the 2-ways binding is the only way that we communicate between View > and ViewModel. Not via interface.
I don't believe John intended the diagram to explicitly disallow other forms of communication. For instance, it's readily accepted by most that EventAggregator is a key part of MVVM, and that certainly allows for other forms of communication. Regardless, yes, it's my very strong opinion that there's nothing in the pattern that disallows services, including a View service, and in fact there are many things that are difficult to do at, at best, without this.
> I believe that "not having any reference to the View from the ViewModel" can > be a part of pattern because we don't want VM to be changed to support the > changes of View.
It's my contention that you don't need to change the ViewModel to support the View even when using loose coupling.
> Actually, pattern has a name. The way of implementing the pattern can be > different and we can combine a few patterns together based on our need. But > still it has a name.
Not just a name, but a definition, and I contend that the definition doesn't, nor should it, include an exclusion to the use of a view service.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
Both these options seems to like more coupling to me. I am doing this via a Message (usually handled by the Shell or some other service) to show messages. That way when in test or minimal dev environments, the message can be sent, but ignored.
On Behalf Of Bill Kempf Sent: Thursday, February 04, 2010 9:25 AM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] Re: MVVM Questions
On Wed, Feb 3, 2010 at 9:51 PM, Michael Sync <mchls...@gmail.com> wrote: > Please help me to take a look at the code below. Is it MVP or MVVM?
> interface IView{
> void ShowMessage(string message);
> }
> class View : IView {
> public void ShowMessage(string message){
> MessageBox.Show(this, message);
> }
> }
> class ViewModel{
> private IView view;
> public ViewModel(IVew view){
> this.view = view;
> }
> ........
> view.ShowMessage("This is a msg");
> }
There's not enough info here to say for sure. It could go either way. I will say, however, that this is not what I would do. Onyx has an IDisplayMessage service for this.
>>>>To some extent, that's a good thing. MVVM is a pattern. Patterns can >>>>be applied in multiple ways. As long as the pattern is still >>>>adhered to, the differing applications are not really relevant. >>>>Things like "not having any reference to the View from the ViewModel" are not part of the pattern. > This is what you believe, right? There are a lot of people who believe > that VM should not have any view reference. According to John's class > diagram <link>, the 2-ways binding is the only way that we communicate > between View and ViewModel. Not via interface.
I don't believe John intended the diagram to explicitly disallow other forms of communication. For instance, it's readily accepted by most that EventAggregator is a key part of MVVM, and that certainly allows for other forms of communication. Regardless, yes, it's my very strong opinion that there's nothing in the pattern that disallows services, including a View service, and in fact there are many things that are difficult to do at, at best, without this.
> I believe that "not having any reference to the View from the > ViewModel" can be a part of pattern because we don't want VM to be > changed to support the changes of View.
It's my contention that you don't need to change the ViewModel to support the View even when using loose coupling.
> Actually, pattern has a name. The way of implementing the pattern can > be different and we can combine a few patterns together based on our > need. But still it has a name.
Not just a name, but a definition, and I contend that the definition doesn't, nor should it, include an exclusion to the use of a view service.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
> wrote: > Both these options seems to like more coupling to me. I am doing this via > a > Message (usually handled by the Shell or some other service) to show > messages. That way when in test or minimal dev environments, the message > can be sent, but ignored.
> Note: This was typed on a big ole laptop so any misspellings and > punctuations are completely my fault…not my phone’s.
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > On Behalf Of Bill Kempf > Sent: Thursday, February 04, 2010 9:25 AM > To: wpf-disciples@googlegroups.com > Subject: Re: [WPF Disciples] Re: MVVM Questions
> On Wed, Feb 3, 2010 at 9:51 PM, Michael Sync <mchls...@gmail.com> wrote: > > Please help me to take a look at the code below. Is it MVP or MVVM?
> > interface IView{
> > void ShowMessage(string message);
> > }
> > class View : IView {
> > public void ShowMessage(string message){
> > MessageBox.Show(this, message);
> > }
> > }
> > class ViewModel{
> > private IView view;
> > public ViewModel(IVew view){
> > this.view = view;
> > }
> > ........
> > view.ShowMessage("This is a msg");
> > }
> There's not enough info here to say for sure. It could go either way. > I will say, however, that this is not what I would do. Onyx has an > IDisplayMessage service for this.
> >>>>To some extent, that's a good thing. MVVM is a pattern. Patterns can > >>>>be applied in multiple ways. As long as the pattern is still > >>>>adhered to, the differing applications are not really relevant. > >>>>Things like "not having any reference to the View from the ViewModel" > are not part of the pattern. > > This is what you believe, right? There are a lot of people who believe > > that VM should not have any view reference. According to John's class > > diagram <link>, the 2-ways binding is the only way that we communicate > > between View and ViewModel. Not via interface.
> I don't believe John intended the diagram to explicitly disallow other > forms > of communication. For instance, it's readily accepted by most that > EventAggregator is a key part of MVVM, and that certainly allows for other > forms of communication. Regardless, yes, it's my very strong opinion that > there's nothing in the pattern that disallows services, including a View > service, and in fact there are many things that are difficult to do at, at > best, without this.
> > I believe that "not having any reference to the View from the > > ViewModel" can be a part of pattern because we don't want VM to be > > changed to support the changes of View.
> It's my contention that you don't need to change the ViewModel to support > the View even when using loose coupling.
> > Actually, pattern has a name. The way of implementing the pattern can > > be different and we can combine a few patterns together based on our > > need. But still it has a name.
> Not just a name, but a definition, and I contend that the definition > doesn't, nor should it, include an exclusion to the use of a view service.
> -- > Quidquid latine dictum sit, altum sonatur. > - Whatever is said in Latin sounds profound.
> War is peace. Freedom is slavery. Bugs are features.
Using a service, when in test or minimal dev environments, the service method can be called, but ignored. You gain nothing by using a Message, and some things can be complicated to accomplish using methods.
<shawn.li...@agilitrain.com> wrote: > Both these options seems to like more coupling to me. I am doing this via a > Message (usually handled by the Shell or some other service) to show > messages. That way when in test or minimal dev environments, the message > can be sent, but ignored.
> Note: This was typed on a big ole laptop so any misspellings and > punctuations are completely my fault…not my phone’s.
> -----Original Message----- > From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] > On Behalf Of Bill Kempf > Sent: Thursday, February 04, 2010 9:25 AM > To: wpf-disciples@googlegroups.com > Subject: Re: [WPF Disciples] Re: MVVM Questions
> On Wed, Feb 3, 2010 at 9:51 PM, Michael Sync <mchls...@gmail.com> wrote: >> Please help me to take a look at the code below. Is it MVP or MVVM?
>> interface IView{
>> void ShowMessage(string message);
>> }
>> class View : IView {
>> public void ShowMessage(string message){
>> MessageBox.Show(this, message);
>> }
>> }
>> class ViewModel{
>> private IView view;
>> public ViewModel(IVew view){
>> this.view = view;
>> }
>> ........
>> view.ShowMessage("This is a msg");
>> }
> There's not enough info here to say for sure. It could go either way. > I will say, however, that this is not what I would do. Onyx has an > IDisplayMessage service for this.
>>>>>To some extent, that's a good thing. MVVM is a pattern. Patterns can >>>>>be applied in multiple ways. As long as the pattern is still >>>>>adhered to, the differing applications are not really relevant. >>>>>Things like "not having any reference to the View from the ViewModel" > are not part of the pattern. >> This is what you believe, right? There are a lot of people who believe >> that VM should not have any view reference. According to John's class >> diagram <link>, the 2-ways binding is the only way that we communicate >> between View and ViewModel. Not via interface.
> I don't believe John intended the diagram to explicitly disallow other forms > of communication. For instance, it's readily accepted by most that > EventAggregator is a key part of MVVM, and that certainly allows for other > forms of communication. Regardless, yes, it's my very strong opinion that > there's nothing in the pattern that disallows services, including a View > service, and in fact there are many things that are difficult to do at, at > best, without this.
>> I believe that "not having any reference to the View from the >> ViewModel" can be a part of pattern because we don't want VM to be >> changed to support the changes of View.
> It's my contention that you don't need to change the ViewModel to support > the View even when using loose coupling.
>> Actually, pattern has a name. The way of implementing the pattern can >> be different and we can combine a few patterns together based on our >> need. But still it has a name.
> Not just a name, but a definition, and I contend that the definition > doesn't, nor should it, include an exclusion to the use of a view service.
> -- > Quidquid latine dictum sit, altum sonatur. > - Whatever is said in Latin sounds profound.
> War is peace. Freedom is slavery. Bugs are features.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
On Thu, Feb 4, 2010 at 3:03 PM, Bill Kempf <weke...@gmail.com> wrote: > Using a service, when in test or minimal dev environments, the service > method can be called, but ignored. You gain nothing by using a > Message, and some things can be complicated to accomplish using > methods.
> On Thu, Feb 4, 2010 at 9:48 AM, Shawn Wildermuth > <shawn.li...@agilitrain.com> wrote: > > Both these options seems to like more coupling to me. I am doing this > via a > > Message (usually handled by the Shell or some other service) to show > > messages. That way when in test or minimal dev environments, the message > > can be sent, but ignored.
> > Note: This was typed on a big ole laptop so any misspellings and > > punctuations are completely my fault…not my phone’s.
> > -----Original Message----- > > From: wpf-disciples@googlegroups.com [mailto: > wpf-disciples@googlegroups.com] > > On Behalf Of Bill Kempf > > Sent: Thursday, February 04, 2010 9:25 AM > > To: wpf-disciples@googlegroups.com > > Subject: Re: [WPF Disciples] Re: MVVM Questions
> > On Wed, Feb 3, 2010 at 9:51 PM, Michael Sync <mchls...@gmail.com> wrote: > >> Please help me to take a look at the code below. Is it MVP or MVVM?
> >> interface IView{
> >> void ShowMessage(string message);
> >> }
> >> class View : IView {
> >> public void ShowMessage(string message){
> >> MessageBox.Show(this, message);
> >> }
> >> }
> >> class ViewModel{
> >> private IView view;
> >> public ViewModel(IVew view){
> >> this.view = view;
> >> }
> >> ........
> >> view.ShowMessage("This is a msg");
> >> }
> > There's not enough info here to say for sure. It could go either way. > > I will say, however, that this is not what I would do. Onyx has an > > IDisplayMessage service for this.
> >>>>>To some extent, that's a good thing. MVVM is a pattern. Patterns can > >>>>>be applied in multiple ways. As long as the pattern is still > >>>>>adhered to, the differing applications are not really relevant. > >>>>>Things like "not having any reference to the View from the ViewModel" > > are not part of the pattern. > >> This is what you believe, right? There are a lot of people who believe > >> that VM should not have any view reference. According to John's class > >> diagram <link>, the 2-ways binding is the only way that we communicate > >> between View and ViewModel. Not via interface.
> > I don't believe John intended the diagram to explicitly disallow other > forms > > of communication. For instance, it's readily accepted by most that > > EventAggregator is a key part of MVVM, and that certainly allows for > other > > forms of communication. Regardless, yes, it's my very strong opinion that > > there's nothing in the pattern that disallows services, including a View > > service, and in fact there are many things that are difficult to do at, > at > > best, without this.
> >> I believe that "not having any reference to the View from the > >> ViewModel" can be a part of pattern because we don't want VM to be > >> changed to support the changes of View.
> > It's my contention that you don't need to change the ViewModel to support > > the View even when using loose coupling.
> >> Actually, pattern has a name. The way of implementing the pattern can > >> be different and we can combine a few patterns together based on our > >> need. But still it has a name.
> > Not just a name, but a definition, and I contend that the definition > > doesn't, nor should it, include an exclusion to the use of a view > service.
> > -- > > Quidquid latine dictum sit, altum sonatur. > > - Whatever is said in Latin sounds profound.
> > War is peace. Freedom is slavery. Bugs are features.
> -- > Quidquid latine dictum sit, altum sonatur. > - Whatever is said in Latin sounds profound.
> War is peace. Freedom is slavery. Bugs are features.
We will probably call *IDisplayMessageService *in CAB,SCSF or Prism, In MVVM, we used to have IDisplayMessageService or IDialogService or etc.
>>a View service
I think you mis-understand me. I'm not talking about IDisplayService or ViewService. I just want to know whether *you have an interface for every views* (like we have in MVP pattern) or not.
>>I would say that is MVP
Yes, Sacha. I raised the same question in other group as well. The most of people believe that this is a MVP.
As of now, I think we have different thoughts about having the interface of View in ViewModel. But good thing is that we all agree for all facts.
Please discuss if anyone like to add more on that..
Thanks for participating in discussion.. I really appreciate it. Actually, I'm sharing some of my idea about MVVM pattern with my team and Singapore Community. The most of people in my team have the working experience with winform (CAB, SCSF and MVP pattern) so I used to get a lot of questions like that.. there are only a few people who are using MVVM (even WPF or Silverlight) so I don't get much people to discuss in SG. This group is the only one that I can discuss online. Thanks again for your suggestion.. :)
Thanks and Best Regards, Michael Sync
Don't go the way life takes you. Take life the way you go
> On Thu, Feb 4, 2010 at 3:03 PM, Bill Kempf <weke...@gmail.com> wrote:
>> Using a service, when in test or minimal dev environments, the service >> method can be called, but ignored. You gain nothing by using a >> Message, and some things can be complicated to accomplish using >> methods.
>> On Thu, Feb 4, 2010 at 9:48 AM, Shawn Wildermuth >> <shawn.li...@agilitrain.com> wrote: >> > Both these options seems to like more coupling to me. I am doing this >> via a >> > Message (usually handled by the Shell or some other service) to show >> > messages. That way when in test or minimal dev environments, the >> message >> > can be sent, but ignored.
>> > Note: This was typed on a big ole laptop so any misspellings and >> > punctuations are completely my fault…not my phone’s.
>> > -----Original Message----- >> > From: wpf-disciples@googlegroups.com [mailto: >> wpf-disciples@googlegroups.com] >> > On Behalf Of Bill Kempf >> > Sent: Thursday, February 04, 2010 9:25 AM >> > To: wpf-disciples@googlegroups.com >> > Subject: Re: [WPF Disciples] Re: MVVM Questions
>> > On Wed, Feb 3, 2010 at 9:51 PM, Michael Sync <mchls...@gmail.com> >> wrote: >> >> Please help me to take a look at the code below. Is it MVP or MVVM?
>> >> interface IView{
>> >> void ShowMessage(string message);
>> >> }
>> >> class View : IView {
>> >> public void ShowMessage(string message){
>> >> MessageBox.Show(this, message);
>> >> }
>> >> }
>> >> class ViewModel{
>> >> private IView view;
>> >> public ViewModel(IVew view){
>> >> this.view = view;
>> >> }
>> >> ........
>> >> view.ShowMessage("This is a msg");
>> >> }
>> > There's not enough info here to say for sure. It could go either way. >> > I will say, however, that this is not what I would do. Onyx has an >> > IDisplayMessage service for this.
>> >>>>>To some extent, that's a good thing. MVVM is a pattern. Patterns can >> >>>>>be applied in multiple ways. As long as the pattern is still >> >>>>>adhered to, the differing applications are not really relevant. >> >>>>>Things like "not having any reference to the View from the >> ViewModel" >> > are not part of the pattern. >> >> This is what you believe, right? There are a lot of people who believe >> >> that VM should not have any view reference. According to John's class >> >> diagram <link>, the 2-ways binding is the only way that we communicate >> >> between View and ViewModel. Not via interface.
>> > I don't believe John intended the diagram to explicitly disallow other >> forms >> > of communication. For instance, it's readily accepted by most that >> > EventAggregator is a key part of MVVM, and that certainly allows for >> other >> > forms of communication. Regardless, yes, it's my very strong opinion >> that >> > there's nothing in the pattern that disallows services, including a View >> > service, and in fact there are many things that are difficult to do at, >> at >> > best, without this.
>> >> I believe that "not having any reference to the View from the >> >> ViewModel" can be a part of pattern because we don't want VM to be >> >> changed to support the changes of View.
>> > It's my contention that you don't need to change the ViewModel to >> support >> > the View even when using loose coupling.
>> >> Actually, pattern has a name. The way of implementing the pattern can >> >> be different and we can combine a few patterns together based on our >> >> need. But still it has a name.
>> > Not just a name, but a definition, and I contend that the definition >> > doesn't, nor should it, include an exclusion to the use of a view >> service.
>> > -- >> > Quidquid latine dictum sit, altum sonatur. >> > - Whatever is said in Latin sounds profound.
>> > War is peace. Freedom is slavery. Bugs are features.
>> -- >> Quidquid latine dictum sit, altum sonatur. >> - Whatever is said in Latin sounds profound.
>> War is peace. Freedom is slavery. Bugs are features.
On Thu, Feb 4, 2010 at 11:11 AM, Michael Sync <mchls...@gmail.com> wrote: > Thanks, Bill, Shawn and Sacha.
>>>Onyx has an IDisplayMessage service for this.
> We will probably call IDisplayMessageService in CAB,SCSF or Prism, In MVVM, > we used to have IDisplayMessageService or IDialogService or etc.
Same concept, different name. It's a service whether you call it one in the name or not.
>>>a View service
> I think you mis-understand me. I'm not talking about IDisplayService or > ViewService. I just want to know whether you have an interface for every > views (like we have in MVP pattern) or not.
Onyx has an IView for every view, yes. IView is a service. It's main purpose is to provide access to other services (it's an IServiceProvider), but it does contain a property called ViewElement that's the actual UIElement of the view. It's also probably going to be gaining Show and Close methods in V2 of the framework. I've gone back and forth on whether or not the ViewElement should be included, because frankly anything you'd do with it could be accomplished with out it using the IServiceProvider, but I have used it once or twice for convenience (and in a manner that was testable and didn't couple me to the specific view instance or implementation). I'll agree that this is controversial, at best, but I'm pragmatic not dogmatic.
>>>I would say that is MVP
> Yes, Sacha. I raised the same question in other group as well. The most of > people believe that this is a MVP.
Why? I don't think you can tell from what little was posted, but I'd love to hear the reasoning.
-- Quidquid latine dictum sit, altum sonatur. - Whatever is said in Latin sounds profound.
War is peace. Freedom is slavery. Bugs are features.
I agree with the good doctor on this. It doesn't matter if it's ViewModel or Presenter it's all poo. In the strictest sense, a viewmodel shouldn't have a reference to a given view.but that guidance is there because should you need it a ViewModel can be reused with multiple views (you could even go so far as having a ViewModel support multiple UI platforms such as WPF/Silverlight and even ASP.NET MVC). If you don't need this capability, ignore that guidance and put what you need into the VM. Just don't go hog wild and consider using interfaces to remove coupling to a SPECIFIC view. Both of these will open options for you in the future to support multiple views and possible even different platforms.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Michael Sync Sent: Wednesday, February 03, 2010 9:52 PM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] Re: MVVM Questions
interface IView{
void ShowMessage(string message);
}
class View : IView {
public void ShowMessage(string message){
MessageBox.Show(this, message);
}
}
class ViewModel{
private IView view;
public ViewModel(IVew view){
this.view = view;
}
........
view.ShowMessage("This is a msg");
} >>>To some extent, that's a good thing. MVVM is a pattern. Patterns can be
applied in multiple ways. As long as the pattern is still adhered to, the differing applications are not really relevant. Things like "not having any reference to the View from the ViewModel" are not part of the pattern.
This is what you believe, right? There are a lot of people who believe that VM should not have any view reference. According to John's class diagram <link <http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx> >, the 2-ways binding is the only way that we communicate between View and ViewModel. Not via interface.
I believe that "not having any reference to the View from the ViewModel" can be a part of pattern because we don't want VM to be changed to support the changes of View.
Actually, pattern has a name. The way of implementing the pattern can be different and we can combine a few patterns together based on our need. But still it has a name.
I try to avoid the ViewModel knowing about the view via an interface if at all possible, preferring instead loosely coupled eventing (as in Prisms). I see this a being 'pure' MVVM, and sometimes it may not be practical. I’d say that in non-arbitrary projects, the message service is better implemented as a service, as I think most of us do anyway.
On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote:
> What about if you and our WPF/Silverlight community create a standard for > MVVM pattern? I understand that there are a lot of way to implement MVVM but > at least, there are some obvious rules that everyone can follow so everyone > has same understanding about that pattern.
> Here are some of my thoughts.
> *Goals*
> - > - Testabiltiy ( ViewModel is easier to unit test than code-behind or > event driven code) > - Clear seperation between UX designer and developer > - Increases the "Blendability" of your view > - Model never needs to be changed to support changes to the view > - ViewModel rarely needs to be changed to support changes to the view > - No duplicated code to update views
> *Do and Don't in View*
> - *shouldn't contain any logic that you want to test* : As Glenn said > that MVVM is not code counting exercise, we can write code in code-behind. > But you should never write any logic that you want to test. For example: If > user select a country then you want to display the list of states or city in > your view. This is the business requirement so you should have unit test to > test this logic. So, you shouldn't write it in code-behind. > - *can be a user control or Data Template* > - *Keep the view as simple as possible. : *We can still use Data Trigger > or Value Converter or Visual State or Blend Behivor in XAML with care. > - *use attached property if something is not bindable : *There is one > common mistake about PasswordBox. We all knows that WPF Password is not > bindable due to the security reason. But if you are having a string property > "Password" in Model then it won't be secure no matter whether you set it > from code-behind or attached property.
> *Do and Don't in ViewModel*
> - An abstraction of View > - Connector between View and Model > - Keep View State, Value Conversion > - No strong or weak (via Interface) reference of View > - Make VM as testable as possible (e.g. no call to Singleton class) > - No Control related Stuff in VM ( Because if you are changing the view > then you will have to change VM as well. )
> *Model *
> - > - can be Data Model, DTO, POCO, auto-generated proxy of domain class and > UI Model based on how you want to have the separation between Domain Service > and Presentation Layer > - No reference to ViewModel
> Thanks and Best Regards, > Michael Sync
> Don't go the way life takes you. > Take life the way you go
> On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com> wrote:
> > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> wrote:
> >> Hi John,
> >> Thanks for creating MVVM pattern. :)
> > To be clear...I didn't actually create it, I learned it from some Smalltalk > > devs and figured out how to use it with WPF...but you're welcome. :-)
> >> >>1) efficiently write rich UI
> >> I agree that we can use MVVM to write rich UI efficiently. But I don't > >> think that MVVM is the only way to write rich UI efficiently. There are a > >> lot of patterns that we can write rich UI ( UI is not just WPF/Silverlight)
> > I didn't say it was the only way. All I said was one of the goals of MVVM > > was to write UI efficiently.
> >> >>2) where the code is maintainable
> >> The same goes for this as well. Writing maintainable code is not just > >> about MVVM.
> >> >>3) the model never needs to be changed to support changes to the view > >> >>4) the viewmodel rarely if ever needs to be changed to support changes > >> to the view > >> >>5) there can be many views of the same viewmodel
> >> Agreed.
> >> >>6) the design is as toolable as possible.
> >> Do you agree the fact that we need to dump the view as much as possible?
> > If by "dump" you mean write as little code as possible in the view, I don't > > think that is a goal. It *may* be part of the solution, but I think the > > real thing is to only have code in the view that actually has to do with the > > view. Animation code may be huge, but as long as it doesn't include > > business logic it is fine in the view.
> >> Do you think that using Data Trigger or Value Converter are anti-MVVM? If > >> yes then what about using Visual State Manager, Blend Behivor, Event or > >> Property Trigger?
> > On the contrary, all those things were created to support the MVVM > > pattern.
> >> Is it okay to have control-related stuffs (like Control Event or etc ) in > >> View Model?
> > No. Then you can't switch what Control (a view thing) you use without > > modifying the ViewModel.
> >> I'd love to hear other's opinion as well for those questions.....
> >> Regards, > >> Michael Sync
> >> Don't go the way life takes you. > >> Take life the way you go
> >> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman <gossmans...@gmail.com>wrote:
> >>> I haven't written anything about MVVM in a while because there is so much > >>> material already being published. However I have been thinking about what > >>> we can do in the platform to make things better and reading a lot of the > >>> public stuff, so I thought I'd summarize for my own sake if nothing else:
> >>> The state of MVVM reminds me of Peter Naur's classic paper "Programming > >>> as Theory Building". He basically says the proper model for computer > >>> programming is not engineering but scientific development where you have > >>> problem, you develop a hypothesis for how to fix it, you experiment (write > >>> code and test it), and then you decide whether you've solved the problem. > >>> If not you synthesize a new hypothesis and try again.
> >>> MVVM feels more like "science" than anything else I've seen...with lots > >>> of authors publishing papers containing their hypotheses and results and > >>> suggesting avenues for further research. Some papers are better than > >>> others, some are revolutionary and some contain nothing new.
> >>> Fundamentally I think the goal of MVVM has still not been clearly > >>> stated. I posit some of the goals include: > >>> 1) efficiently write rich UI > >>> 2) where the code is maintainable > >>> 3) the model never needs to be changed to support changes to the view > >>> 4) the viewmodel rarely if ever needs to be changed to support changes to > >>> the view > >>> 5) there can be many views of the same viewmodel > >>> 6) the design is as toolable as possible.
> >>> To my mind #6 is the most important and perhaps the one we still have > >>> made the least progress with. Blend Behaviors are a huge step in the right > >>> direction, but we need to go further.
> >>> I don't think eliminating all code from the View is part of the goal, > >>> though it obviously makes some of the others easier. When it makes them > >>> harder though, one should write view code (though whether that means the > >>> code behind model or something else is not clear).
> >>> Among the next steps, I would like to eliminate the boilerplate code for > >>> INotifyPropertyChanged (and eventually eliminate DependencyProperties and > >>> DependencyObjects and allow any property on any class to support binding and > >>> change notification). Further I would like to bind events in the View > >>> directly to Commands on the ViewModel so you can say <Button Click="{Binding > >>> SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This > >>> leads to the question whether ICommand itself is just boilerplate and we can > >>> simply remove it with binding directly to methods. The downside being it > >>> isn't clear all methods can/should be called from the View in which case it > >>> may be useful to have contract (currently offered by the list of properties > >>> of type ICommand). On the tooling side I would like to see a UI where you > >>> can select a control, see a list of the events it supports and choose which > >>> methods on the ViewModel you want them to trigger. This leads in turn to > >>> how to handle event arguments like keys. Keybinding is already pretty good, > >>> but the syntax should be simple.
>>I try to avoid the ViewModel knowing about the view via an interface
if at all possible
+1 Daniel. Though I try to avoid the *event aggregator* if the event needs to be published from the View, like in the case of IActiveAware. In that scenario I might go into a cheaper/lazy MVP style by opening up the IViewModel with an IViewModel.SetActive(...) and storing ref to IViewModel on my IView.SetViewModel(...).
On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote: > I try to avoid the ViewModel knowing about the view via an interface > if at all possible, preferring instead loosely coupled eventing (as in > Prisms). I see this a being 'pure' MVVM, and sometimes it may not be > practical. > I’d say that in non-arbitrary projects, the message service is better > implemented as a service, as I think most of us do anyway.
> On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote: > > Thanks a lot, John. I'm really appreciate it.
> > What about if you and our WPF/Silverlight community create a standard for > > MVVM pattern? I understand that there are a lot of way to implement MVVM > but > > at least, there are some obvious rules that everyone can follow so > everyone > > has same understanding about that pattern.
> > Here are some of my thoughts.
> > *Goals*
> > - > > - Testabiltiy ( ViewModel is easier to unit test than code-behind or > > event driven code) > > - Clear seperation between UX designer and developer > > - Increases the "Blendability" of your view > > - Model never needs to be changed to support changes to the view > > - ViewModel rarely needs to be changed to support changes to the view > > - No duplicated code to update views
> > *Do and Don't in View*
> > - *shouldn't contain any logic that you want to test* : As Glenn said > > that MVVM is not code counting exercise, we can write code in > code-behind. > > But you should never write any logic that you want to test. For > example: If > > user select a country then you want to display the list of states or > city in > > your view. This is the business requirement so you should have unit > test to > > test this logic. So, you shouldn't write it in code-behind. > > - *can be a user control or Data Template* > > - *Keep the view as simple as possible. : *We can still use Data > Trigger > > or Value Converter or Visual State or Blend Behivor in XAML with care. > > - *use attached property if something is not bindable : *There is one > > common mistake about PasswordBox. We all knows that WPF Password is > not > > bindable due to the security reason. But if you are having a string > property > > "Password" in Model then it won't be secure no matter whether you set > it > > from code-behind or attached property.
> > *Do and Don't in ViewModel*
> > - An abstraction of View > > - Connector between View and Model > > - Keep View State, Value Conversion > > - No strong or weak (via Interface) reference of View > > - Make VM as testable as possible (e.g. no call to Singleton class) > > - No Control related Stuff in VM ( Because if you are changing the > view > > then you will have to change VM as well. )
> > *Model *
> > - > > - can be Data Model, DTO, POCO, auto-generated proxy of domain class > and > > UI Model based on how you want to have the separation between Domain > Service > > and Presentation Layer > > - No reference to ViewModel
> > Thanks and Best Regards, > > Michael Sync
> > Don't go the way life takes you. > > Take life the way you go
> > On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com> > wrote:
> > > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> > wrote:
> > >> Hi John,
> > >> Thanks for creating MVVM pattern. :)
> > > To be clear...I didn't actually create it, I learned it from some > Smalltalk > > > devs and figured out how to use it with WPF...but you're welcome. :-)
> > >> >>1) efficiently write rich UI
> > >> I agree that we can use MVVM to write rich UI efficiently. But I don't > > >> think that MVVM is the only way to write rich UI efficiently. There > are a > > >> lot of patterns that we can write rich UI ( UI is not just > WPF/Silverlight)
> > > I didn't say it was the only way. All I said was one of the goals of > MVVM > > > was to write UI efficiently.
> > >> >>2) where the code is maintainable
> > >> The same goes for this as well. Writing maintainable code is not just > > >> about MVVM.
> > >> >>3) the model never needs to be changed to support changes to the > view > > >> >>4) the viewmodel rarely if ever needs to be changed to support > changes > > >> to the view > > >> >>5) there can be many views of the same viewmodel
> > >> Agreed.
> > >> >>6) the design is as toolable as possible.
> > >> Do you agree the fact that we need to dump the view as much as > possible?
> > > If by "dump" you mean write as little code as possible in the view, I > don't > > > think that is a goal. It *may* be part of the solution, but I think > the > > > real thing is to only have code in the view that actually has to do > with the > > > view. Animation code may be huge, but as long as it doesn't include > > > business logic it is fine in the view.
> > >> Do you think that using Data Trigger or Value Converter are anti-MVVM? > If > > >> yes then what about using Visual State Manager, Blend Behivor, Event > or > > >> Property Trigger?
> > > On the contrary, all those things were created to support the MVVM > > > pattern.
> > >> Is it okay to have control-related stuffs (like Control Event or etc ) > in > > >> View Model?
> > > No. Then you can't switch what Control (a view thing) you use without > > > modifying the ViewModel.
> > >> I'd love to hear other's opinion as well for those questions.....
> > >> Regards, > > >> Michael Sync
> > >> Don't go the way life takes you. > > >> Take life the way you go
> > >> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman <gossmans...@gmail.com > >wrote:
> > >>> I haven't written anything about MVVM in a while because there is so > much > > >>> material already being published. However I have been thinking about > what > > >>> we can do in the platform to make things better and reading a lot of > the > > >>> public stuff, so I thought I'd summarize for my own sake if nothing > else:
> > >>> The state of MVVM reminds me of Peter Naur's classic paper > "Programming > > >>> as Theory Building". He basically says the proper model for computer > > >>> programming is not engineering but scientific development where you > have > > >>> problem, you develop a hypothesis for how to fix it, you experiment > (write > > >>> code and test it), and then you decide whether you've solved the > problem. > > >>> If not you synthesize a new hypothesis and try again.
> > >>> MVVM feels more like "science" than anything else I've seen...with > lots > > >>> of authors publishing papers containing their hypotheses and results > and > > >>> suggesting avenues for further research. Some papers are better than > > >>> others, some are revolutionary and some contain nothing new.
> > >>> Fundamentally I think the goal of MVVM has still not been clearly > > >>> stated. I posit some of the goals include: > > >>> 1) efficiently write rich UI > > >>> 2) where the code is maintainable > > >>> 3) the model never needs to be changed to support changes to the view > > >>> 4) the viewmodel rarely if ever needs to be changed to support > changes to > > >>> the view > > >>> 5) there can be many views of the same viewmodel > > >>> 6) the design is as toolable as possible.
> > >>> To my mind #6 is the most important and perhaps the one we still have > > >>> made the least progress with. Blend Behaviors are a huge step in the > right > > >>> direction, but we need to go further.
> > >>> I don't think eliminating all code from the View is part of the goal, > > >>> though it obviously makes some of the others easier. When it makes > them > > >>> harder though, one should write view code (though whether that means > the > > >>> code behind model or something else is not clear).
> > >>> Among the next steps, I would like to eliminate the boilerplate code > for > > >>> INotifyPropertyChanged (and eventually eliminate DependencyProperties > and > > >>> DependencyObjects and allow any property on any class to support > binding and > > >>> change notification). Further I would like to bind events in the > View > > >>> directly to Commands on the ViewModel so you can say <Button > Click="{Binding > > >>> SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. > This > > >>> leads to the question whether ICommand itself is just boilerplate and > we can > > >>> simply remove it with binding directly to methods. The downside > being it > > >>> isn't clear all methods can/should be called from the View in which > case it > > >>> may be useful to have contract (currently offered by the list of > properties > > >>> of type ICommand). On the tooling side I would like to see a UI > where you > > >>> can select a control, see a list of the events it supports and choose > which > > >>> methods on the ViewModel you want them to trigger. This leads in > turn to > > >>> how to handle event arguments like keys. Keybinding is already > pretty good, > > >>> but the syntax should be simple.
Let me be clearer, I use commanding (or a Behavior) to talk to the VM and the VM can issue the message (a la the Messenger in MVVM Light, or EventAggregator (which is growing too much trouble for me)).
Note: This was typed on a big ole laptop so any misspellings and punctuations are completely my fault.not my phone's.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Jeremiah Morrill Sent: Thursday, February 04, 2010 6:29 PM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] Re: MVVM Questions
>>I try to avoid the ViewModel knowing about the view via an interface
if at all possible
+1 Daniel. Though I try to avoid the event aggregator if the event needs to be published from the View, like in the case of IActiveAware. In that scenario I might go into a cheaper/lazy MVP style by opening up the IViewModel with an IViewModel.SetActive(...) and storing ref to IViewModel on my IView.SetViewModel(...).
On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote:
I try to avoid the ViewModel knowing about the view via an interface if at all possible, preferring instead loosely coupled eventing (as in Prisms). I see this a being 'pure' MVVM, and sometimes it may not be practical. I'd say that in non-arbitrary projects, the message service is better implemented as a service, as I think most of us do anyway.
On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote:
> What about if you and our WPF/Silverlight community create a standard for > MVVM pattern? I understand that there are a lot of way to implement MVVM but > at least, there are some obvious rules that everyone can follow so everyone > has same understanding about that pattern.
> Here are some of my thoughts.
> *Goals*
> - > - Testabiltiy ( ViewModel is easier to unit test than code-behind or > event driven code) > - Clear seperation between UX designer and developer > - Increases the "Blendability" of your view > - Model never needs to be changed to support changes to the view > - ViewModel rarely needs to be changed to support changes to the view > - No duplicated code to update views
> *Do and Don't in View*
> - *shouldn't contain any logic that you want to test* : As Glenn said > that MVVM is not code counting exercise, we can write code in code-behind. > But you should never write any logic that you want to test. For example: If > user select a country then you want to display the list of states or city in > your view. This is the business requirement so you should have unit test to > test this logic. So, you shouldn't write it in code-behind. > - *can be a user control or Data Template* > - *Keep the view as simple as possible. : *We can still use Data Trigger > or Value Converter or Visual State or Blend Behivor in XAML with care. > - *use attached property if something is not bindable : *There is one > common mistake about PasswordBox. We all knows that WPF Password is not > bindable due to the security reason. But if you are having a string property > "Password" in Model then it won't be secure no matter whether you set it > from code-behind or attached property.
> *Do and Don't in ViewModel*
> - An abstraction of View > - Connector between View and Model > - Keep View State, Value Conversion > - No strong or weak (via Interface) reference of View > - Make VM as testable as possible (e.g. no call to Singleton class) > - No Control related Stuff in VM ( Because if you are changing the view > then you will have to change VM as well. )
> *Model *
> - > - can be Data Model, DTO, POCO, auto-generated proxy of domain class and > UI Model based on how you want to have the separation between Domain Service > and Presentation Layer > - No reference to ViewModel
> Thanks and Best Regards, > Michael Sync
> Don't go the way life takes you. > Take life the way you go
> > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> wrote:
> >> Hi John,
> >> Thanks for creating MVVM pattern. :)
> > To be clear...I didn't actually create it, I learned it from some Smalltalk > > devs and figured out how to use it with WPF...but you're welcome. :-)
> >> >>1) efficiently write rich UI
> >> I agree that we can use MVVM to write rich UI efficiently. But I don't > >> think that MVVM is the only way to write rich UI efficiently. There are a > >> lot of patterns that we can write rich UI ( UI is not just WPF/Silverlight)
> > I didn't say it was the only way. All I said was one of the goals of MVVM > > was to write UI efficiently.
> >> >>2) where the code is maintainable
> >> The same goes for this as well. Writing maintainable code is not just > >> about MVVM.
> >> >>3) the model never needs to be changed to support changes to the view > >> >>4) the viewmodel rarely if ever needs to be changed to support changes > >> to the view > >> >>5) there can be many views of the same viewmodel
> >> Agreed.
> >> >>6) the design is as toolable as possible.
> >> Do you agree the fact that we need to dump the view as much as possible?
> > If by "dump" you mean write as little code as possible in the view, I don't > > think that is a goal. It *may* be part of the solution, but I think the > > real thing is to only have code in the view that actually has to do with the > > view. Animation code may be huge, but as long as it doesn't include > > business logic it is fine in the view.
> >> Do you think that using Data Trigger or Value Converter are anti-MVVM? If > >> yes then what about using Visual State Manager, Blend Behivor, Event or > >> Property Trigger?
> > On the contrary, all those things were created to support the MVVM > > pattern.
> >> Is it okay to have control-related stuffs (like Control Event or etc ) in > >> View Model?
> > No. Then you can't switch what Control (a view thing) you use without > > modifying the ViewModel.
> >> I'd love to hear other's opinion as well for those questions.....
> >> Regards, > >> Michael Sync
> >> Don't go the way life takes you. > >> Take life the way you go
> >>> I haven't written anything about MVVM in a while because there is so much > >>> material already being published. However I have been thinking about what > >>> we can do in the platform to make things better and reading a lot of the > >>> public stuff, so I thought I'd summarize for my own sake if nothing else:
> >>> The state of MVVM reminds me of Peter Naur's classic paper "Programming > >>> as Theory Building". He basically says the proper model for computer > >>> programming is not engineering but scientific development where you have > >>> problem, you develop a hypothesis for how to fix it, you experiment (write > >>> code and test it), and then you decide whether you've solved the problem. > >>> If not you synthesize a new hypothesis and try again.
> >>> MVVM feels more like "science" than anything else I've seen...with lots > >>> of authors publishing papers containing their hypotheses and results and > >>> suggesting avenues for further research. Some papers are better than > >>> others, some are revolutionary and some contain nothing new.
> >>> Fundamentally I think the goal of MVVM has still not been clearly > >>> stated. I posit some of the goals include: > >>> 1) efficiently write rich UI > >>> 2) where the code is maintainable > >>> 3) the model never needs to be changed to support changes to the view > >>> 4) the viewmodel rarely if ever needs to be changed to support changes to > >>> the view > >>> 5) there can be many views of the same viewmodel > >>> 6) the design is as toolable as possible.
> >>> To my mind #6 is the most important and perhaps the one we still have > >>> made the least progress with. Blend Behaviors are a huge step in the right > >>> direction, but we need to go further.
> >>> I don't think eliminating all code from the View is part of the goal, > >>> though it obviously makes some of the others easier. When it makes them > >>> harder though, one should write view code (though whether that means the > >>> code behind model or something else is not clear).
> >>> Among the next steps, I would like to eliminate the boilerplate code for > >>> INotifyPropertyChanged (and eventually eliminate DependencyProperties and > >>> DependencyObjects and allow any property on any class to support binding and > >>> change notification). Further I would like to bind events in the View > >>> directly to Commands on the ViewModel so you can say <Button Click="{Binding > >>> SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. This > >>> leads to the question whether ICommand itself is just boilerplate and we can > >>> simply remove it with binding directly to methods. The downside being it > >>> isn't clear all methods can/should be called from the View in which case it > >>> may be useful to have contract (currently offered by the list of properties > >>> of type ICommand). On the tooling side I would like to see a UI where you > >>> can select a control, see a list of the events it supports and choose which > >>> methods on the ViewModel you want them to trigger. This leads in turn to > >>> how to handle event arguments like keys. Keybinding is already pretty good, > >>> but the syntax should be simple.
Jer, do you find the IViewModel.SetActive(...) approach to be useful where a viewmodel oversees multiple views? I myself, generally go 1 to 1, but that’s just me. I would probably avoid having a means to set the View using a base interface because it could be overused, but again it’s a matter of preference.
On Feb 5, 12:29 am, Jeremiah Morrill <jeremiah.morr...@gmail.com> wrote:
> >>I try to avoid the ViewModel knowing about the view via an interface
> if at all possible
> +1 Daniel. Though I try to avoid the *event aggregator* if the event needs > to be published from the View, like in the case of IActiveAware. In that > scenario I might go into a cheaper/lazy MVP style by opening up the > IViewModel with an IViewModel.SetActive(...) and storing ref to IViewModel > on my IView.SetViewModel(...).
> On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote: > > I try to avoid the ViewModel knowing about the view via an interface > > if at all possible, preferring instead loosely coupled eventing (as in > > Prisms). I see this a being 'pure' MVVM, and sometimes it may not be > > practical. > > I’d say that in non-arbitrary projects, the message service is better > > implemented as a service, as I think most of us do anyway.
> > On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote: > > > Thanks a lot, John. I'm really appreciate it.
> > > What about if you and our WPF/Silverlight community create a standard for > > > MVVM pattern? I understand that there are a lot of way to implement MVVM > > but > > > at least, there are some obvious rules that everyone can follow so > > everyone > > > has same understanding about that pattern.
> > > Here are some of my thoughts.
> > > *Goals*
> > > - > > > - Testabiltiy ( ViewModel is easier to unit test than code-behind or > > > event driven code) > > > - Clear seperation between UX designer and developer > > > - Increases the "Blendability" of your view > > > - Model never needs to be changed to support changes to the view > > > - ViewModel rarely needs to be changed to support changes to the view > > > - No duplicated code to update views
> > > *Do and Don't in View*
> > > - *shouldn't contain any logic that you want to test* : As Glenn said > > > that MVVM is not code counting exercise, we can write code in > > code-behind. > > > But you should never write any logic that you want to test. For > > example: If > > > user select a country then you want to display the list of states or > > city in > > > your view. This is the business requirement so you should have unit > > test to > > > test this logic. So, you shouldn't write it in code-behind. > > > - *can be a user control or Data Template* > > > - *Keep the view as simple as possible. : *We can still use Data > > Trigger > > > or Value Converter or Visual State or Blend Behivor in XAML with care. > > > - *use attached property if something is not bindable : *There is one > > > common mistake about PasswordBox. We all knows that WPF Password is > > not > > > bindable due to the security reason. But if you are having a string > > property > > > "Password" in Model then it won't be secure no matter whether you set > > it > > > from code-behind or attached property.
> > > *Do and Don't in ViewModel*
> > > - An abstraction of View > > > - Connector between View and Model > > > - Keep View State, Value Conversion > > > - No strong or weak (via Interface) reference of View > > > - Make VM as testable as possible (e.g. no call to Singleton class) > > > - No Control related Stuff in VM ( Because if you are changing the > > view > > > then you will have to change VM as well. )
> > > *Model *
> > > - > > > - can be Data Model, DTO, POCO, auto-generated proxy of domain class > > and > > > UI Model based on how you want to have the separation between Domain > > Service > > > and Presentation Layer > > > - No reference to ViewModel
> > > Thanks and Best Regards, > > > Michael Sync
> > > Don't go the way life takes you. > > > Take life the way you go
> > > On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com> > > wrote:
> > > > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> > > wrote:
> > > >> Hi John,
> > > >> Thanks for creating MVVM pattern. :)
> > > > To be clear...I didn't actually create it, I learned it from some > > Smalltalk > > > > devs and figured out how to use it with WPF...but you're welcome. :-)
> > > >> >>1) efficiently write rich UI
> > > >> I agree that we can use MVVM to write rich UI efficiently. But I don't > > > >> think that MVVM is the only way to write rich UI efficiently. There > > are a > > > >> lot of patterns that we can write rich UI ( UI is not just > > WPF/Silverlight)
> > > > I didn't say it was the only way. All I said was one of the goals of > > MVVM > > > > was to write UI efficiently.
> > > >> >>2) where the code is maintainable
> > > >> The same goes for this as well. Writing maintainable code is not just > > > >> about MVVM.
> > > >> >>3) the model never needs to be changed to support changes to the > > view > > > >> >>4) the viewmodel rarely if ever needs to be changed to support > > changes > > > >> to the view > > > >> >>5) there can be many views of the same viewmodel
> > > >> Agreed.
> > > >> >>6) the design is as toolable as possible.
> > > >> Do you agree the fact that we need to dump the view as much as > > possible?
> > > > If by "dump" you mean write as little code as possible in the view, I > > don't > > > > think that is a goal. It *may* be part of the solution, but I think > > the > > > > real thing is to only have code in the view that actually has to do > > with the > > > > view. Animation code may be huge, but as long as it doesn't include > > > > business logic it is fine in the view.
> > > >> Do you think that using Data Trigger or Value Converter are anti-MVVM? > > If > > > >> yes then what about using Visual State Manager, Blend Behivor, Event > > or > > > >> Property Trigger?
> > > > On the contrary, all those things were created to support the MVVM > > > > pattern.
> > > >> Is it okay to have control-related stuffs (like Control Event or etc ) > > in > > > >> View Model?
> > > > No. Then you can't switch what Control (a view thing) you use without > > > > modifying the ViewModel.
> > > >> I'd love to hear other's opinion as well for those questions.....
> > > >> Regards, > > > >> Michael Sync
> > > >> Don't go the way life takes you. > > > >> Take life the way you go
> > > >> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman <gossmans...@gmail.com > > >wrote:
> > > >>> I haven't written anything about MVVM in a while because there is so > > much > > > >>> material already being published. However I have been thinking about > > what > > > >>> we can do in the platform to make things better and reading a lot of > > the > > > >>> public stuff, so I thought I'd summarize for my own sake if nothing > > else:
> > > >>> The state of MVVM reminds me of Peter Naur's classic paper > > "Programming > > > >>> as Theory Building". He basically says the proper model for computer > > > >>> programming is not engineering but scientific development where you > > have > > > >>> problem, you develop a hypothesis for how to fix it, you experiment > > (write > > > >>> code and test it), and then you decide whether you've solved the > > problem. > > > >>> If not you synthesize a new hypothesis and try again.
> > > >>> MVVM feels more like "science" than anything else I've seen...with > > lots > > > >>> of authors publishing papers containing their hypotheses and results > > and > > > >>> suggesting avenues for further research. Some papers are better than > > > >>> others, some are revolutionary and some contain nothing new.
> > > >>> Fundamentally I think the goal of MVVM has still not been clearly > > > >>> stated. I posit some of the goals include: > > > >>> 1) efficiently write rich UI > > > >>> 2) where the code is maintainable > > > >>> 3) the model never needs to be changed to support changes to the view > > > >>> 4) the viewmodel rarely if ever needs to be changed to support > > changes to > > > >>> the view > > > >>> 5) there can be many views of the same viewmodel > > > >>> 6) the design is as toolable as possible.
> > > >>> To my mind #6 is the most important and perhaps the one we still have > > > >>> made the least progress with. Blend Behaviors are a huge step in the > > right > > > >>> direction, but we need to go further.
> > > >>> I don't think eliminating all code from the View is part of the goal, > > > >>> though it obviously makes some of the others easier. When it makes > > them > > > >>> harder though, one should write view code (though whether that means > > the > > > >>> code behind model or something else is not clear).
> > > >>> Among the next steps, I would like to eliminate the boilerplate code > > for > > > >>> INotifyPropertyChanged (and eventually eliminate DependencyProperties > > and > > > >>> DependencyObjects and allow any property on any class to support > > binding and > > > >>> change notification). Further I would like to bind events in the > > View > > > >>> directly to Commands on the ViewModel so you can say <Button > > Click="{Binding > > > >>> SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. > > This > > > >>> leads to the question whether ICommand itself is just boilerplate and > > we can > > > >>> simply remove it with binding directly to methods. The downside > > being it > > > >>> isn't clear all methods can/should be called from the View in which > > case it > > > >>> may be useful to have
> Let me be clearer, I use commanding (or a Behavior) to talk to the VM and > the VM can issue the message (a la the Messenger in MVVM Light, or > EventAggregator (which is growing too much trouble for me)).
> Note: This was typed on a big ole laptop so any misspellings and > punctuations are completely my fault.not my phone's.
> From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] > On Behalf Of Jeremiah Morrill > Sent: Thursday, February 04, 2010 6:29 PM > To: wpf-disciples@googlegroups.com > Subject: Re: [WPF Disciples] Re: MVVM Questions
> >>I try to avoid the ViewModel knowing about the view via an interface
> if at all possible
> +1 Daniel. Though I try to avoid the event aggregator if the event needs to > be published from the View, like in the case of IActiveAware. In that > scenario I might go into a cheaper/lazy MVP style by opening up the > IViewModel with an IViewModel.SetActive(...) and storing ref to IViewModel > on my IView.SetViewModel(...).
> On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote:
> I try to avoid the ViewModel knowing about the view via an interface > if at all possible, preferring instead loosely coupled eventing (as in > Prisms). I see this a being 'pure' MVVM, and sometimes it may not be > practical. > I'd say that in non-arbitrary projects, the message service is better > implemented as a service, as I think most of us do anyway.
> On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote:
> > Thanks a lot, John. I'm really appreciate it.
> > What about if you and our WPF/Silverlight community create a standard for > > MVVM pattern? I understand that there are a lot of way to implement MVVM > but > > at least, there are some obvious rules that everyone can follow so > everyone > > has same understanding about that pattern.
> > Here are some of my thoughts.
> > *Goals*
> > - > > - Testabiltiy ( ViewModel is easier to unit test than code-behind or > > event driven code) > > - Clear seperation between UX designer and developer > > - Increases the "Blendability" of your view > > - Model never needs to be changed to support changes to the view > > - ViewModel rarely needs to be changed to support changes to the view > > - No duplicated code to update views
> > *Do and Don't in View*
> > - *shouldn't contain any logic that you want to test* : As Glenn said > > that MVVM is not code counting exercise, we can write code in > code-behind. > > But you should never write any logic that you want to test. For > example: If > > user select a country then you want to display the list of states or > city in > > your view. This is the business requirement so you should have unit > test to > > test this logic. So, you shouldn't write it in code-behind. > > - *can be a user control or Data Template* > > - *Keep the view as simple as possible. : *We can still use Data > Trigger > > or Value Converter or Visual State or Blend Behivor in XAML with care. > > - *use attached property if something is not bindable : *There is one > > common mistake about PasswordBox. We all knows that WPF Password is not > > bindable due to the security reason. But if you are having a string > property > > "Password" in Model then it won't be secure no matter whether you set > it > > from code-behind or attached property.
> > *Do and Don't in ViewModel*
> > - An abstraction of View > > - Connector between View and Model > > - Keep View State, Value Conversion > > - No strong or weak (via Interface) reference of View > > - Make VM as testable as possible (e.g. no call to Singleton class) > > - No Control related Stuff in VM ( Because if you are changing the view > > then you will have to change VM as well. )
> > *Model *
> > - > > - can be Data Model, DTO, POCO, auto-generated proxy of domain class > and > > UI Model based on how you want to have the separation between Domain > Service > > and Presentation Layer > > - No reference to ViewModel
> > Thanks and Best Regards, > > Michael Sync
> > Don't go the way life takes you. > > Take life the way you go
> > On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com>
> wrote:
> > > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> > wrote:
> > >> Hi John,
> > >> Thanks for creating MVVM pattern. :)
> > > To be clear...I didn't actually create it, I learned it from some > Smalltalk > > > devs and figured out how to use it with WPF...but you're welcome. :-)
> > >> >>1) efficiently write rich UI
> > >> I agree that we can use MVVM to write rich UI efficiently. But I don't > > >> think that MVVM is the only way to write rich UI efficiently. There are > a > > >> lot of patterns that we can write rich UI ( UI is not just > WPF/Silverlight)
> > > I didn't say it was the only way. All I said was one of the goals of > MVVM > > > was to write UI efficiently.
> > >> >>2) where the code is maintainable
> > >> The same goes for this as well. Writing maintainable code is not just > > >> about MVVM.
> > >> >>3) the model never needs to be changed to support changes to the view > > >> >>4) the viewmodel rarely if ever needs to be changed to support > changes > > >> to the view > > >> >>5) there can be many views of the same viewmodel
> > >> Agreed.
> > >> >>6) the design is as toolable as possible.
> > >> Do you agree the fact that we need to dump the view as much as > possible?
> > > If by "dump" you mean write as little code as possible in the view, I > don't > > > think that is a goal. It *may* be part of the solution, but I think the > > > real thing is to only have code in the view that actually has to do with > the > > > view. Animation code may be huge, but as long as it doesn't include > > > business logic it is fine in the view.
> > >> Do you think that using Data Trigger or Value Converter are anti-MVVM? > If > > >> yes then what about using Visual State Manager, Blend Behivor, Event or > > >> Property Trigger?
> > > On the contrary, all those things were created to support the MVVM > > > pattern.
> > >> Is it okay to have control-related stuffs (like Control Event or etc ) > in > > >> View Model?
> > > No. Then you can't switch what Control (a view thing) you use without > > > modifying the ViewModel.
> > >> I'd love to hear other's opinion as well for those questions.....
> > >> Regards, > > >> Michael Sync
> > >> Don't go the way life takes you. > > >> Take life the way you go
> > >>> I haven't written anything about MVVM in a while because there is so > much > > >>> material already being published. However I have been thinking about > what > > >>> we can do in the platform to make things better and reading a lot of > the > > >>> public stuff, so I thought I'd summarize for my own sake if nothing > else:
> > >>> The state of MVVM reminds me of Peter Naur's classic paper > "Programming > > >>> as Theory Building". He basically says the proper model for computer > > >>> programming is not engineering but scientific development where you > have > > >>> problem, you develop a hypothesis for how to fix it, you experiment > (write > > >>> code and test it), and then you decide whether you've solved the > problem. > > >>> If not you synthesize a new hypothesis and try again.
> > >>> MVVM feels more like "science" than anything else I've seen...with > lots > > >>> of authors publishing papers containing their hypotheses and results > and > > >>> suggesting avenues for further research. Some papers are better than > > >>> others, some are revolutionary and some contain nothing new.
> > >>> Fundamentally I think the goal of MVVM has still not been clearly > > >>> stated. I posit some of the goals include: > > >>> 1) efficiently write rich UI > > >>> 2) where the code is maintainable > > >>> 3) the model never needs to be changed to support changes to the view > > >>> 4) the viewmodel rarely if ever needs to be changed to support changes > to > > >>> the view > > >>> 5) there can be many views of the same viewmodel > > >>> 6) the design is as toolable as possible.
> > >>> To my mind #6 is the most important and perhaps the one we still have > > >>> made the least progress with. Blend Behaviors are a huge step in the > right > > >>> direction, but we need to go further.
> > >>> I don't think eliminating all code from the View is part of the goal, > > >>> though it obviously makes some of the others easier. When it makes > them > > >>> harder though, one should write view code (though whether that means > the > > >>> code behind model or something else is not clear).
> > >>> Among the next steps, I would like to eliminate the boilerplate code > for > > >>> INotifyPropertyChanged (and eventually eliminate DependencyProperties > and > > >>> DependencyObjects and allow any property on any class to support > binding and > > >>> change notification). Further I would like to bind events in the View > > >>> directly to Commands on the ViewModel so you can say <Button > Click="{Binding > > >>> SaveCommand}" MouseRightButtonUp="{Binding ShowContextCommand}"/>. > This > > >>> leads to the question whether ICommand itself is just boilerplate and > we can > > >>> simply remove it with binding directly to methods. The downside being > it > > >>> isn't clear all methods can/should be called from the View
Totally right..can be overused..which is a problem in it's own. But for special cases (like IActiveAware, which has to be implemented on your IView class), I find it to be elegant. So far, I've only had to mix up some MVP and MVVM a few times.
In my code, the only thing that knows what an IView's concrete type is my IoC container. My typical IView looks like this:
public interface IView { void SetViewModel(IViewModel viewModel)
}
and my IViewModel:
public interface IViewModel { object View{get;}//read-only
}
and the concrete VM:
public class ViewModel : IViewModel { public ViewModel(IView view) { view.SetViewModel(this); View = view; }
public object View{get;private set;}
}
I would say 9/10 of my V/VM's look almost exactly like this (no extra interface methods, interface properties) and one method. The view never storing the IViewModel beyond setting the DataContext. But you see how this method makes it ripe for mixing MVP...and ripe for abuse ;)
On Thu, Feb 4, 2010 at 3:50 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote: > Jer, do you find the IViewModel.SetActive(...) approach to be useful > where a viewmodel oversees multiple views? I myself, generally go 1 to > 1, but that’s just me. I would probably avoid having a means to set > the View using a base interface because it could be overused, but > again it’s a matter of preference.
> On Feb 5, 12:29 am, Jeremiah Morrill <jeremiah.morr...@gmail.com> > wrote: > > >>I try to avoid the ViewModel knowing about the view via an interface
> > if at all possible
> > +1 Daniel. Though I try to avoid the *event aggregator* if the event > needs > > to be published from the View, like in the case of IActiveAware. In that > > scenario I might go into a cheaper/lazy MVP style by opening up the > > IViewModel with an IViewModel.SetActive(...) and storing ref to > IViewModel > > on my IView.SetViewModel(...).
> > On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> > wrote: > > > I try to avoid the ViewModel knowing about the view via an interface > > > if at all possible, preferring instead loosely coupled eventing (as in > > > Prisms). I see this a being 'pure' MVVM, and sometimes it may not be > > > practical. > > > I’d say that in non-arbitrary projects, the message service is better > > > implemented as a service, as I think most of us do anyway.
> > > On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote: > > > > Thanks a lot, John. I'm really appreciate it.
> > > > What about if you and our WPF/Silverlight community create a standard > for > > > > MVVM pattern? I understand that there are a lot of way to implement > MVVM > > > but > > > > at least, there are some obvious rules that everyone can follow so > > > everyone > > > > has same understanding about that pattern.
> > > > Here are some of my thoughts.
> > > > *Goals*
> > > > - > > > > - Testabiltiy ( ViewModel is easier to unit test than code-behind > or > > > > event driven code) > > > > - Clear seperation between UX designer and developer > > > > - Increases the "Blendability" of your view > > > > - Model never needs to be changed to support changes to the view > > > > - ViewModel rarely needs to be changed to support changes to the > view > > > > - No duplicated code to update views
> > > > *Do and Don't in View*
> > > > - *shouldn't contain any logic that you want to test* : As Glenn > said > > > > that MVVM is not code counting exercise, we can write code in > > > code-behind. > > > > But you should never write any logic that you want to test. For > > > example: If > > > > user select a country then you want to display the list of states > or > > > city in > > > > your view. This is the business requirement so you should have > unit > > > test to > > > > test this logic. So, you shouldn't write it in code-behind. > > > > - *can be a user control or Data Template* > > > > - *Keep the view as simple as possible. : *We can still use Data > > > Trigger > > > > or Value Converter or Visual State or Blend Behivor in XAML with > care. > > > > - *use attached property if something is not bindable : *There is > one > > > > common mistake about PasswordBox. We all knows that WPF Password > is > > > not > > > > bindable due to the security reason. But if you are having a > string > > > property > > > > "Password" in Model then it won't be secure no matter whether you > set > > > it > > > > from code-behind or attached property.
> > > > *Do and Don't in ViewModel*
> > > > - An abstraction of View > > > > - Connector between View and Model > > > > - Keep View State, Value Conversion > > > > - No strong or weak (via Interface) reference of View > > > > - Make VM as testable as possible (e.g. no call to Singleton > class) > > > > - No Control related Stuff in VM ( Because if you are changing the > > > view > > > > then you will have to change VM as well. )
> > > > *Model *
> > > > - > > > > - can be Data Model, DTO, POCO, auto-generated proxy of domain > class > > > and > > > > UI Model based on how you want to have the separation between > Domain > > > Service > > > > and Presentation Layer > > > > - No reference to ViewModel
> > > > Thanks and Best Regards, > > > > Michael Sync
> > > > Don't go the way life takes you. > > > > Take life the way you go
> > > > On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com
> > > wrote:
> > > > > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> > > > wrote:
> > > > >> Hi John,
> > > > >> Thanks for creating MVVM pattern. :)
> > > > > To be clear...I didn't actually create it, I learned it from some > > > Smalltalk > > > > > devs and figured out how to use it with WPF...but you're welcome. > :-)
> > > > >> >>1) efficiently write rich UI
> > > > >> I agree that we can use MVVM to write rich UI efficiently. But I > don't > > > > >> think that MVVM is the only way to write rich UI efficiently. > There > > > are a > > > > >> lot of patterns that we can write rich UI ( UI is not just > > > WPF/Silverlight)
> > > > > I didn't say it was the only way. All I said was one of the goals > of > > > MVVM > > > > > was to write UI efficiently.
> > > > >> >>2) where the code is maintainable
> > > > >> The same goes for this as well. Writing maintainable code is not > just > > > > >> about MVVM.
> > > > >> >>3) the model never needs to be changed to support changes to the > > > view > > > > >> >>4) the viewmodel rarely if ever needs to be changed to support > > > changes > > > > >> to the view > > > > >> >>5) there can be many views of the same viewmodel
> > > > >> Agreed.
> > > > >> >>6) the design is as toolable as possible.
> > > > >> Do you agree the fact that we need to dump the view as much as > > > possible?
> > > > > If by "dump" you mean write as little code as possible in the view, > I > > > don't > > > > > think that is a goal. It *may* be part of the solution, but I > think > > > the > > > > > real thing is to only have code in the view that actually has to do > > > with the > > > > > view. Animation code may be huge, but as long as it doesn't > include > > > > > business logic it is fine in the view.
> > > > >> Do you think that using Data Trigger or Value Converter are > anti-MVVM? > > > If > > > > >> yes then what about using Visual State Manager, Blend Behivor, > Event > > > or > > > > >> Property Trigger?
> > > > > On the contrary, all those things were created to support the MVVM > > > > > pattern.
> > > > >> Is it okay to have control-related stuffs (like Control Event or > etc ) > > > in > > > > >> View Model?
> > > > > No. Then you can't switch what Control (a view thing) you use > without > > > > > modifying the ViewModel.
> > > > >> I'd love to hear other's opinion as well for those questions.....
> > > > >> Regards, > > > > >> Michael Sync
> > > > >> Don't go the way life takes you. > > > > >> Take life the way you go
> > > > >> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman < > gossmans...@gmail.com > > > >wrote:
> > > > >>> I haven't written anything about MVVM in a while because there is > so > > > much > > > > >>> material already being published. However I have been thinking > about > > > what > > > > >>> we can do in the platform to make things better and reading a lot > of > > > the > > > > >>> public stuff, so I thought I'd summarize for my own sake if > nothing > > > else:
> > > > >>> The state of MVVM reminds me of Peter Naur's classic paper > > > "Programming > > > > >>> as Theory Building". He basically says the proper model for > computer > > > > >>> programming is not engineering but scientific development where > you > > > have > > > > >>> problem, you develop a hypothesis for how to fix it, you > experiment > > > (write > > > > >>> code and test it), and then you decide whether you've solved the > > > problem. > > > > >>> If not you synthesize a new hypothesis and try again.
> > > > >>> MVVM feels more like "science" than anything else I've > seen...with > > > lots > > > > >>> of authors publishing papers containing their hypotheses and > results > > > and > > > > >>> suggesting avenues for further research. Some papers are better > than > > > > >>> others, some are revolutionary and some contain nothing new.
> > > > >>> Fundamentally I think the goal of MVVM has still not been clearly > > > > >>> stated. I posit some of the goals include: > > > > >>> 1) efficiently write rich UI > > > > >>> 2) where the code is maintainable > > > > >>> 3) the model never needs to be changed to support changes to the > view > > > > >>> 4) the viewmodel rarely if ever
Curious, in your SetViewModel, you're specifying an interface. Since I rely heavily on binding, I just accept an object (since the bindings are basically duck-typed). What are you getting out of the interface?
Note: This was typed on a big ole laptop so any misspellings and punctuations are completely my fault.not my phone's.
From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] On Behalf Of Jeremiah Morrill Sent: Thursday, February 04, 2010 7:10 PM To: wpf-disciples@googlegroups.com Subject: Re: [WPF Disciples] Re: MVVM Questions
Totally right..can be overused..which is a problem in it's own. But for special cases (like IActiveAware, which has to be implemented on your IView class), I find it to be elegant. So far, I've only had to mix up some MVP and MVVM a few times.
In my code, the only thing that knows what an IView's concrete type is my IoC container. My typical IView looks like this:
public interface IView
{
void SetViewModel(IViewModel viewModel)
}
and my IViewModel:
public interface IViewModel
{
object View{get;}//read-only
}
and the concrete VM:
public class ViewModel : IViewModel
{
public ViewModel(IView view)
{
view.SetViewModel(this);
View = view;
}
public object View{get;private set;}
}
I would say 9/10 of my V/VM's look almost exactly like this (no extra interface methods, interface properties) and one method. The view never storing the IViewModel beyond setting the DataContext. But you see how this method makes it ripe for mixing MVP...and ripe for abuse ;)
-Jer
On Thu, Feb 4, 2010 at 3:50 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote:
Jer, do you find the IViewModel.SetActive(...) approach to be useful where a viewmodel oversees multiple views? I myself, generally go 1 to 1, but that's just me. I would probably avoid having a means to set the View using a base interface because it could be overused, but again it's a matter of preference.
On Feb 5, 12:29 am, Jeremiah Morrill <jeremiah.morr...@gmail.com>
> >>I try to avoid the ViewModel knowing about the view via an interface
> if at all possible
> +1 Daniel. Though I try to avoid the *event aggregator* if the event needs > to be published from the View, like in the case of IActiveAware. In that > scenario I might go into a cheaper/lazy MVP style by opening up the > IViewModel with an IViewModel.SetActive(...) and storing ref to IViewModel > on my IView.SetViewModel(...).
> On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote: > > I try to avoid the ViewModel knowing about the view via an interface > > if at all possible, preferring instead loosely coupled eventing (as in > > Prisms). I see this a being 'pure' MVVM, and sometimes it may not be > > practical. > > I'd say that in non-arbitrary projects, the message service is better > > implemented as a service, as I think most of us do anyway.
> > On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote: > > > Thanks a lot, John. I'm really appreciate it.
> > > What about if you and our WPF/Silverlight community create a standard for > > > MVVM pattern? I understand that there are a lot of way to implement MVVM > > but > > > at least, there are some obvious rules that everyone can follow so > > everyone > > > has same understanding about that pattern.
> > > Here are some of my thoughts.
> > > *Goals*
> > > - > > > - Testabiltiy ( ViewModel is easier to unit test than code-behind or > > > event driven code) > > > - Clear seperation between UX designer and developer > > > - Increases the "Blendability" of your view > > > - Model never needs to be changed to support changes to the view > > > - ViewModel rarely needs to be changed to support changes to the view > > > - No duplicated code to update views
> > > *Do and Don't in View*
> > > - *shouldn't contain any logic that you want to test* : As Glenn said > > > that MVVM is not code counting exercise, we can write code in > > code-behind. > > > But you should never write any logic that you want to test. For > > example: If > > > user select a country then you want to display the list of states or > > city in > > > your view. This is the business requirement so you should have unit > > test to > > > test this logic. So, you shouldn't write it in code-behind. > > > - *can be a user control or Data Template* > > > - *Keep the view as simple as possible. : *We can still use Data > > Trigger > > > or Value Converter or Visual State or Blend Behivor in XAML with care. > > > - *use attached property if something is not bindable : *There is one > > > common mistake about PasswordBox. We all knows that WPF Password is > > not > > > bindable due to the security reason. But if you are having a string > > property > > > "Password" in Model then it won't be secure no matter whether you set > > it > > > from code-behind or attached property.
> > > *Do and Don't in ViewModel*
> > > - An abstraction of View > > > - Connector between View and Model > > > - Keep View State, Value Conversion > > > - No strong or weak (via Interface) reference of View > > > - Make VM as testable as possible (e.g. no call to Singleton class) > > > - No Control related Stuff in VM ( Because if you are changing the > > view > > > then you will have to change VM as well. )
> > > *Model *
> > > - > > > - can be Data Model, DTO, POCO, auto-generated proxy of domain class > > and > > > UI Model based on how you want to have the separation between Domain > > Service > > > and Presentation Layer > > > - No reference to ViewModel
> > > Thanks and Best Regards, > > > Michael Sync
> > > Don't go the way life takes you. > > > Take life the way you go
> > > On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com> > > wrote:
> > > > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> > > wrote:
> > > >> Hi John,
> > > >> Thanks for creating MVVM pattern. :)
> > > > To be clear...I didn't actually create it, I learned it from some > > Smalltalk > > > > devs and figured out how to use it with WPF...but you're welcome. :-)
> > > >> >>1) efficiently write rich UI
> > > >> I agree that we can use MVVM to write rich UI efficiently. But I don't > > > >> think that MVVM is the only way to write rich UI efficiently. There > > are a > > > >> lot of patterns that we can write rich UI ( UI is not just > > WPF/Silverlight)
> > > > I didn't say it was the only way. All I said was one of the goals of > > MVVM > > > > was to write UI efficiently.
> > > >> >>2) where the code is maintainable
> > > >> The same goes for this as well. Writing maintainable code is not just > > > >> about MVVM.
> > > >> >>3) the model never needs to be changed to support changes to the > > view > > > >> >>4) the viewmodel rarely if ever needs to be changed to support > > changes > > > >> to the view > > > >> >>5) there can be many views of the same viewmodel
> > > >> Agreed.
> > > >> >>6) the design is as toolable as possible.
> > > >> Do you agree the fact that we need to dump the view as much as > > possible?
> > > > If by "dump" you mean write as little code as possible in the view, I > > don't > > > > think that is a goal. It *may* be part of the solution, but I think > > the > > > > real thing is to only have code in the view that actually has to do > > with the > > > > view. Animation code may be huge, but as long as it doesn't include > > > > business logic it is fine in the view.
> > > >> Do you think that using Data Trigger or Value Converter are anti-MVVM? > > If > > > >> yes then what about using Visual State Manager, Blend Behivor, Event > > or > > > >> Property Trigger?
> > > > On the contrary, all those things were created to support the MVVM > > > > pattern.
> > > >> Is it okay to have control-related stuffs (like Control Event or etc ) > > in > > > >> View Model?
> > > > No. Then you can't switch what Control (a view thing) you use without > > > > modifying the ViewModel.
> > > >> I'd love to hear other's opinion as well for those questions.....
> > > >> Regards, > > > >> Michael Sync
> > > >> Don't go the way life takes you. > > > >> Take life the way you go
> > > >> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman <gossmans...@gmail.com > > >wrote:
> > > >>> I haven't written anything about MVVM in a while because there is so > > much > > > >>> material already being published. However I have been thinking about > > what > > > >>> we can do in the platform to make things better and reading a lot of > > the > > > >>> public stuff, so I thought I'd summarize for my own sake if nothing > > else:
> > > >>> The state of MVVM reminds me of Peter Naur's classic paper > > "Programming > > > >>> as Theory Building". He basically says the proper model for computer > > > >>> programming is not engineering but scientific development where you > > have > > > >>> problem, you develop a hypothesis for how to fix it, you experiment > > (write > > > >>> code and test it), and then you decide whether you've solved the > > problem. > > > >>> If not you synthesize a new hypothesis and try again.
> > > >>> MVVM feels more like "science" than anything else I've seen...with > > lots > > > >>> of authors publishing papers containing their hypotheses and results > > and > > > >>> suggesting avenues for further research. Some papers are better than > > > >>> others, some are revolutionary and some contain nothing new.
> > > >>> Fundamentally I think the goal of MVVM has still not been clearly > > > >>> stated. I posit some of the goals include: > > > >>> 1) efficiently write rich UI
Another approach might be to make the View property setter on the ViewModel base implementation internal, and set it using some factory mechanism. Then the IActiveAware could be fulfilled without exposing the ViewModel to subclasses. What do you think?
On Feb 5, 1:09 am, Jeremiah Morrill <jeremiah.morr...@gmail.com> wrote:
> Totally right..can be overused..which is a problem in it's own. But for > special cases (like IActiveAware, which has to be implemented on your IView > class), I find it to be elegant. So far, I've only had to mix up some MVP > and MVVM a few times.
> In my code, the only thing that knows what an IView's concrete type is my > IoC container. My typical IView looks like this:
> public interface IView > { > void SetViewModel(IViewModel viewModel)
> }
> and my IViewModel:
> public interface IViewModel > { > object View{get;}//read-only
> }
> and the concrete VM:
> public class ViewModel : IViewModel > { > public ViewModel(IView view) > { > view.SetViewModel(this); > View = view; > }
> public object View{get;private set;}
> }
> I would say 9/10 of my V/VM's look almost exactly like this (no extra > interface methods, interface properties) and one method. The view never > storing the IViewModel beyond setting the DataContext. But you see how this > method makes it ripe for mixing MVP...and ripe for abuse ;)
> -Jer
> On Thu, Feb 4, 2010 at 3:50 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote: > > Jer, do you find the IViewModel.SetActive(...) approach to be useful > > where a viewmodel oversees multiple views? I myself, generally go 1 to > > 1, but that’s just me. I would probably avoid having a means to set > > the View using a base interface because it could be overused, but > > again it’s a matter of preference.
> > On Feb 5, 12:29 am, Jeremiah Morrill <jeremiah.morr...@gmail.com> > > wrote: > > > >>I try to avoid the ViewModel knowing about the view via an interface
> > > if at all possible
> > > +1 Daniel. Though I try to avoid the *event aggregator* if the event > > needs > > > to be published from the View, like in the case of IActiveAware. In that > > > scenario I might go into a cheaper/lazy MVP style by opening up the > > > IViewModel with an IViewModel.SetActive(...) and storing ref to > > IViewModel > > > on my IView.SetViewModel(...).
> > > On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> > > wrote: > > > > I try to avoid the ViewModel knowing about the view via an interface > > > > if at all possible, preferring instead loosely coupled eventing (as in > > > > Prisms). I see this a being 'pure' MVVM, and sometimes it may not be > > > > practical. > > > > I’d say that in non-arbitrary projects, the message service is better > > > > implemented as a service, as I think most of us do anyway.
> > > > On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote: > > > > > Thanks a lot, John. I'm really appreciate it.
> > > > > What about if you and our WPF/Silverlight community create a standard > > for > > > > > MVVM pattern? I understand that there are a lot of way to implement > > MVVM > > > > but > > > > > at least, there are some obvious rules that everyone can follow so > > > > everyone > > > > > has same understanding about that pattern.
> > > > > Here are some of my thoughts.
> > > > > *Goals*
> > > > > - > > > > > - Testabiltiy ( ViewModel is easier to unit test than code-behind > > or > > > > > event driven code) > > > > > - Clear seperation between UX designer and developer > > > > > - Increases the "Blendability" of your view > > > > > - Model never needs to be changed to support changes to the view > > > > > - ViewModel rarely needs to be changed to support changes to the > > view > > > > > - No duplicated code to update views
> > > > > *Do and Don't in View*
> > > > > - *shouldn't contain any logic that you want to test* : As Glenn > > said > > > > > that MVVM is not code counting exercise, we can write code in > > > > code-behind. > > > > > But you should never write any logic that you want to test. For > > > > example: If > > > > > user select a country then you want to display the list of states > > or > > > > city in > > > > > your view. This is the business requirement so you should have > > unit > > > > test to > > > > > test this logic. So, you shouldn't write it in code-behind. > > > > > - *can be a user control or Data Template* > > > > > - *Keep the view as simple as possible. : *We can still use Data > > > > Trigger > > > > > or Value Converter or Visual State or Blend Behivor in XAML with > > care. > > > > > - *use attached property if something is not bindable : *There is > > one > > > > > common mistake about PasswordBox. We all knows that WPF Password > > is > > > > not > > > > > bindable due to the security reason. But if you are having a > > string > > > > property > > > > > "Password" in Model then it won't be secure no matter whether you > > set > > > > it > > > > > from code-behind or attached property.
> > > > > *Do and Don't in ViewModel*
> > > > > - An abstraction of View > > > > > - Connector between View and Model > > > > > - Keep View State, Value Conversion > > > > > - No strong or weak (via Interface) reference of View > > > > > - Make VM as testable as possible (e.g. no call to Singleton > > class) > > > > > - No Control related Stuff in VM ( Because if you are changing the > > > > view > > > > > then you will have to change VM as well. )
> > > > > *Model *
> > > > > - > > > > > - can be Data Model, DTO, POCO, auto-generated proxy of domain > > class > > > > and > > > > > UI Model based on how you want to have the separation between > > Domain > > > > Service > > > > > and Presentation Layer > > > > > - No reference to ViewModel
> > > > > Thanks and Best Regards, > > > > > Michael Sync
> > > > > Don't go the way life takes you. > > > > > Take life the way you go
> > > > > On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com
> > > > wrote:
> > > > > > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> > > > > wrote:
> > > > > >> Hi John,
> > > > > >> Thanks for creating MVVM pattern. :)
> > > > > > To be clear...I didn't actually create it, I learned it from some > > > > Smalltalk > > > > > > devs and figured out how to use it with WPF...but you're welcome. > > :-)
> > > > > >> >>1) efficiently write rich UI
> > > > > >> I agree that we can use MVVM to write rich UI efficiently. But I > > don't > > > > > >> think that MVVM is the only way to write rich UI efficiently. > > There > > > > are a > > > > > >> lot of patterns that we can write rich UI ( UI is not just > > > > WPF/Silverlight)
> > > > > > I didn't say it was the only way. All I said was one of the goals > > of > > > > MVVM > > > > > > was to write UI efficiently.
> > > > > >> >>2) where the code is maintainable
> > > > > >> The same goes for this as well. Writing maintainable code is not > > just > > > > > >> about MVVM.
> > > > > >> >>3) the model never needs to be changed to support changes to the > > > > view > > > > > >> >>4) the viewmodel rarely if ever needs to be changed to support > > > > changes > > > > > >> to the view > > > > > >> >>5) there can be many views of the same viewmodel
> > > > > >> Agreed.
> > > > > >> >>6) the design is as toolable as possible.
> > > > > >> Do you agree the fact that we need to dump the view as much as > > > > possible?
> > > > > > If by "dump" you mean write as little code as possible in the view, > > I > > > > don't > > > > > > think that is a goal. It *may* be part of the solution, but I > > think > > > > the > > > > > > real thing is to only have code in the view that actually has to do > > > > with the > > > > > > view. Animation code may be huge, but as long as it doesn't > > include > > > > > > business logic it is fine in the view.
> > > > > >> Do you think that using Data Trigger or Value Converter are > > anti-MVVM? > > > > If > > > > > >> yes then what about using Visual State Manager, Blend Behivor, > > Event > > > > or > > > > > >> Property Trigger?
> > > > > > On the contrary, all those things were created to support the MVVM > > > > > > pattern.
> > > > > >> Is it okay to have control-related stuffs (like Control Event or > > etc ) > > > > in > > > > > >> View Model?
> > > > > > No. Then you can't switch what Control (a view thing) you use > > without > > > > > > modifying the ViewModel.
> > > > > >> I'd love to hear other's opinion as well for those questions.....
> > > > > >> Regards, > > > > > >> Michael Sync
> > > > > >> Don't go the way life takes you. > > > > > >> Take life the way you go
> > > > > >> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman < > > gossmans...@gmail.com > > > > >wrote:
> > > > > >>> I haven't written anything about MVVM in a while because there is > > so > > > > much > > > > > >>> material already being published. However I have been thinking > > about > > > > what > > > > > >>> we can do in the platform to make things better and reading a lot > > of > > > > the > > > > > >>> public stuff, so I thought I'd summarize for my own sake if > > nothing > > > > else:
> > > > > >>> The state of MVVM reminds me of Peter Naur's classic paper > > > > "Programming > > > > > >>> as Theory Building". He basically says the proper model for > > computer > > > > > >>> programming is not engineering but scientific development where > > you > > > > have > > > > > >>> problem, you develop a hypothesis for how to fix it, you > > experiment > > > > (write > > > > > >>> code and test it),
I think for almost all usages, an object type would be fine in the SetViewModel(...). The only advantage I can see, beyond being ready for some MVP *sloppiness, *is that on the VM ctor, when I run the IView.SetViewModel(this), I get strong-typing on my one-to-one view/viewmodel. Maybe I just do it out of habit? ;)
On Thu, Feb 4, 2010 at 4:28 PM, Shawn Wildermuth <shawn.li...@agilitrain.com
> wrote: > Curious, in your SetViewModel, you’re specifying an interface. Since I > rely heavily on binding, I just accept an object (since the bindings are > basically duck-typed). What are you getting out of the interface?
> Totally right..can be overused..which is a problem in it's own. But for > special cases (like IActiveAware, which has to be implemented on your IView > class), I find it to be elegant. So far, I've only had to mix up some MVP > and MVVM a few times.
> In my code, the only thing that knows what an IView's concrete type is my > IoC container. My typical IView looks like this:
> public interface IView
> {
> void SetViewModel(IViewModel viewModel)
> }
> and my IViewModel:
> public interface IViewModel
> {
> object View{get;}//read-only
> }
> and the concrete VM:
> public class ViewModel : IViewModel
> {
> public ViewModel(IView view)
> {
> view.SetViewModel(this);
> View = view;
> }
> public object View{get;private set;}
> }
> I would say 9/10 of my V/VM's look almost exactly like this (no extra > interface methods, interface properties) and one method. The view never > storing the IViewModel beyond setting the DataContext. But you see how this > method makes it ripe for mixing MVP...and ripe for abuse ;)
> -Jer
> On Thu, Feb 4, 2010 at 3:50 PM, Daniel Vaughan <dbvaug...@gmail.com> > wrote:
> Jer, do you find the IViewModel.SetActive(...) approach to be useful > where a viewmodel oversees multiple views? I myself, generally go 1 to > 1, but that’s just me. I would probably avoid having a means to set > the View using a base interface because it could be overused, but > again it’s a matter of preference.
> On Feb 5, 12:29 am, Jeremiah Morrill <jeremiah.morr...@gmail.com>
> wrote: > > >>I try to avoid the ViewModel knowing about the view via an interface
> > if at all possible
> > +1 Daniel. Though I try to avoid the *event aggregator* if the event > needs > > to be published from the View, like in the case of IActiveAware. In that > > scenario I might go into a cheaper/lazy MVP style by opening up the > > IViewModel with an IViewModel.SetActive(...) and storing ref to > IViewModel > > on my IView.SetViewModel(...).
> > On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> > wrote: > > > I try to avoid the ViewModel knowing about the view via an interface > > > if at all possible, preferring instead loosely coupled eventing (as in > > > Prisms). I see this a being 'pure' MVVM, and sometimes it may not be > > > practical. > > > I’d say that in non-arbitrary projects, the message service is better > > > implemented as a service, as I think most of us do anyway.
> > > On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote: > > > > Thanks a lot, John. I'm really appreciate it.
> > > > What about if you and our WPF/Silverlight community create a standard > for > > > > MVVM pattern? I understand that there are a lot of way to implement > MVVM > > > but > > > > at least, there are some obvious rules that everyone can follow so > > > everyone > > > > has same understanding about that pattern.
> > > > Here are some of my thoughts.
> > > > *Goals*
> > > > - > > > > - Testabiltiy ( ViewModel is easier to unit test than code-behind > or > > > > event driven code) > > > > - Clear seperation between UX designer and developer > > > > - Increases the "Blendability" of your view > > > > - Model never needs to be changed to support changes to the view > > > > - ViewModel rarely needs to be changed to support changes to the > view > > > > - No duplicated code to update views
> > > > *Do and Don't in View*
> > > > - *shouldn't contain any logic that you want to test* : As Glenn > said > > > > that MVVM is not code counting exercise, we can write code in > > > code-behind. > > > > But you should never write any logic that you want to test. For > > > example: If > > > > user select a country then you want to display the list of states > or > > > city in > > > > your view. This is the business requirement so you should have > unit > > > test to > > > > test this logic. So, you shouldn't write it in code-behind. > > > > - *can be a user control or Data Template* > > > > - *Keep the view as simple as possible. : *We can still use Data > > > Trigger > > > > or Value Converter or Visual State or Blend Behivor in XAML with > care. > > > > - *use attached property if something is not bindable : *There is > one > > > > common mistake about PasswordBox. We all knows that WPF Password > is > > > not > > > > bindable due to the security reason. But if you are having a > string > > > property > > > > "Password" in Model then it won't be secure no matter whether you > set > > > it > > > > from code-behind or attached property.
> > > > *Do and Don't in ViewModel*
> > > > - An abstraction of View > > > > - Connector between View and Model > > > > - Keep View State, Value Conversion > > > > - No strong or weak (via Interface) reference of View > > > > - Make VM as testable as possible (e.g. no call to Singleton > class) > > > > - No Control related Stuff in VM ( Because if you are changing the > > > view > > > > then you will have to change VM as well. )
> > > > *Model *
> > > > - > > > > - can be Data Model, DTO, POCO, auto-generated proxy of domain > class > > > and > > > > UI Model based on how you want to have the separation between > Domain > > > Service > > > > and Presentation Layer > > > > - No reference to ViewModel
> > > > Thanks and Best Regards, > > > > Michael Sync
> > > > Don't go the way life takes you. > > > > Take life the way you go
> > > > On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com
> > > wrote:
> > > > > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> > > > wrote:
> > > > >> Hi John,
> > > > >> Thanks for creating MVVM pattern. :)
> > > > > To be clear...I didn't actually create it, I learned it from some > > > Smalltalk > > > > > devs and figured out how to use it with WPF...but you're welcome. > :-)
> > > > >> >>1) efficiently write rich UI
> > > > >> I agree that we can use MVVM to write rich UI efficiently. But I > don't > > > > >> think that MVVM is the only way to write rich UI efficiently. > There > > > are a > > > > >> lot of patterns that we can write rich UI ( UI is not just > > > WPF/Silverlight)
> > > > > I didn't say it was the only way. All I said was one of the goals > of > > > MVVM > > > > > was to write UI efficiently.
> > > > >> >>2) where the code is maintainable
> > > > >> The same goes for this as well. Writing maintainable code is not > just > > > > >> about MVVM.
> > > > >> >>3) the model never needs to be changed to support changes to the > > > view > > > > >> >>4) the viewmodel rarely if ever needs to be changed to support > > > changes > > > > >> to the view > > > > >> >>5) there can be many views of the same viewmodel
> > > > >> Agreed.
> > > > >> >>6) the design is as toolable as possible.
> > > > >> Do you agree the fact that we need to dump the view as much as > > > possible?
> > > > > If by "dump" you mean write as little code as possible in the view, > I > > > don't > > > > > think that is a goal. It *may* be part of the solution, but I > think > > > the > > > > > real thing is to only have code in the view that actually has to do > > > with the > > > > > view. Animation code may be huge, but as long as it doesn't > include > > > > > business logic it is fine in the view.
> > > > >> Do you think that using Data Trigger or Value Converter are > anti-MVVM? > > > If > > > > >> yes then what about using Visual State Manager, Blend Behivor, > Event > > > or > > > > >> Property Trigger?
> > > > > On the contrary, all those things were created to support the MVVM > > > > > pattern.
> > > > >> Is it okay to have control-related stuffs (like Control Event or > etc ) > > > in > > > > >> View Model?
> > > > > No. Then you can't switch what Control (a view thing) you use > without > > > > > modifying the ViewModel.
> > > > >> I'd love to hear other's opinion as well for those questions.....
> > > > >> Regards, > > > > >> Michael Sync
> > > > >> Don't go the way life takes you. > > > > >> Take life the way you go
> > > > >> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman < > gossmans...@gmail.com > > > >wrote:
> > > > >>> I haven't written anything about MVVM in a while because there is > so > > > much > > > > >>> material already being published. However I have been thinking > about > > > what > > > > >>> we can do in the platform to make things better and reading a lot > of > > > the > > > > >>> public stuff, so I thought I'd summarize for my own sake if > nothing
Daniel, I'm not sure I follow. The IView (and VM) are both instantiated by IoC. IActiveAware is only used by the IRegionManager, but implemented on your view. I need to let the VM know when the RegionManager sets IActiveAware.IsActive has changed. So the way I understand my options are I could use a message bus in code-behind, MVP style communication back to the VM in code-behind, or inherit my IView from IActiveAware and hook into the IsActiveChanged event from the VM (which I guess would be the same as MVP style).
On Thu, Feb 4, 2010 at 4:35 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote: > Another approach might be to make the View property setter on the > ViewModel base implementation internal, and set it using some factory > mechanism. Then the IActiveAware could be fulfilled without exposing > the ViewModel to subclasses. What do you think?
> On Feb 5, 1:09 am, Jeremiah Morrill <jeremiah.morr...@gmail.com> > wrote: > > Totally right..can be overused..which is a problem in it's own. But for > > special cases (like IActiveAware, which has to be implemented on your > IView > > class), I find it to be elegant. So far, I've only had to mix up some > MVP > > and MVVM a few times.
> > In my code, the only thing that knows what an IView's concrete type is my > > IoC container. My typical IView looks like this:
> > public class ViewModel : IViewModel > > { > > public ViewModel(IView view) > > { > > view.SetViewModel(this); > > View = view; > > }
> > public object View{get;private set;}
> > }
> > I would say 9/10 of my V/VM's look almost exactly like this (no extra > > interface methods, interface properties) and one method. The view never > > storing the IViewModel beyond setting the DataContext. But you see how > this > > method makes it ripe for mixing MVP...and ripe for abuse ;)
> > -Jer
> > On Thu, Feb 4, 2010 at 3:50 PM, Daniel Vaughan <dbvaug...@gmail.com> > wrote: > > > Jer, do you find the IViewModel.SetActive(...) approach to be useful > > > where a viewmodel oversees multiple views? I myself, generally go 1 to > > > 1, but that’s just me. I would probably avoid having a means to set > > > the View using a base interface because it could be overused, but > > > again it’s a matter of preference.
> > > On Feb 5, 12:29 am, Jeremiah Morrill <jeremiah.morr...@gmail.com> > > > wrote: > > > > >>I try to avoid the ViewModel knowing about the view via an > interface
> > > > if at all possible
> > > > +1 Daniel. Though I try to avoid the *event aggregator* if the event > > > needs > > > > to be published from the View, like in the case of IActiveAware. In > that > > > > scenario I might go into a cheaper/lazy MVP style by opening up the > > > > IViewModel with an IViewModel.SetActive(...) and storing ref to > > > IViewModel > > > > on my IView.SetViewModel(...).
> > > > On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> > > > wrote: > > > > > I try to avoid the ViewModel knowing about the view via an > interface > > > > > if at all possible, preferring instead loosely coupled eventing (as > in > > > > > Prisms). I see this a being 'pure' MVVM, and sometimes it may not > be > > > > > practical. > > > > > I’d say that in non-arbitrary projects, the message service is > better > > > > > implemented as a service, as I think most of us do anyway.
> > > > > On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote: > > > > > > Thanks a lot, John. I'm really appreciate it.
> > > > > > What about if you and our WPF/Silverlight community create a > standard > > > for > > > > > > MVVM pattern? I understand that there are a lot of way to > implement > > > MVVM > > > > > but > > > > > > at least, there are some obvious rules that everyone can follow > so > > > > > everyone > > > > > > has same understanding about that pattern.
> > > > > > Here are some of my thoughts.
> > > > > > *Goals*
> > > > > > - > > > > > > - Testabiltiy ( ViewModel is easier to unit test than > code-behind > > > or > > > > > > event driven code) > > > > > > - Clear seperation between UX designer and developer > > > > > > - Increases the "Blendability" of your view > > > > > > - Model never needs to be changed to support changes to the > view > > > > > > - ViewModel rarely needs to be changed to support changes to > the > > > view > > > > > > - No duplicated code to update views
> > > > > > *Do and Don't in View*
> > > > > > - *shouldn't contain any logic that you want to test* : As > Glenn > > > said > > > > > > that MVVM is not code counting exercise, we can write code in > > > > > code-behind. > > > > > > But you should never write any logic that you want to test. > For > > > > > example: If > > > > > > user select a country then you want to display the list of > states > > > or > > > > > city in > > > > > > your view. This is the business requirement so you should have > > > unit > > > > > test to > > > > > > test this logic. So, you shouldn't write it in code-behind. > > > > > > - *can be a user control or Data Template* > > > > > > - *Keep the view as simple as possible. : *We can still use > Data > > > > > Trigger > > > > > > or Value Converter or Visual State or Blend Behivor in XAML > with > > > care. > > > > > > - *use attached property if something is not bindable : *There > is > > > one > > > > > > common mistake about PasswordBox. We all knows that WPF > Password > > > is > > > > > not > > > > > > bindable due to the security reason. But if you are having a > > > string > > > > > property > > > > > > "Password" in Model then it won't be secure no matter whether > you > > > set > > > > > it > > > > > > from code-behind or attached property.
> > > > > > *Do and Don't in ViewModel*
> > > > > > - An abstraction of View > > > > > > - Connector between View and Model > > > > > > - Keep View State, Value Conversion > > > > > > - No strong or weak (via Interface) reference of View > > > > > > - Make VM as testable as possible (e.g. no call to Singleton > > > class) > > > > > > - No Control related Stuff in VM ( Because if you are changing > the > > > > > view > > > > > > then you will have to change VM as well. )
> > > > > > *Model *
> > > > > > - > > > > > > - can be Data Model, DTO, POCO, auto-generated proxy of domain > > > class > > > > > and > > > > > > UI Model based on how you want to have the separation between > > > Domain > > > > > Service > > > > > > and Presentation Layer > > > > > > - No reference to ViewModel
> > > > > > Thanks and Best Regards, > > > > > > Michael Sync
> > > > > > Don't go the way life takes you. > > > > > > Take life the way you go
> > > > > > > To be clear...I didn't actually create it, I learned it from > some > > > > > Smalltalk > > > > > > > devs and figured out how to use it with WPF...but you're > welcome. > > > :-)
> > > > > > >> >>1) efficiently write rich UI
> > > > > > >> I agree that we can use MVVM to write rich UI efficiently. But > I > > > don't > > > > > > >> think that MVVM is the only way to write rich UI efficiently. > > > There > > > > > are a > > > > > > >> lot of patterns that we can write rich UI ( UI is not just > > > > > WPF/Silverlight)
> > > > > > > I didn't say it was the only way. All I said was one of the > goals > > > of > > > > > MVVM > > > > > > > was to write UI efficiently.
> > > > > > >> >>2) where the code is maintainable
> > > > > > >> The same goes for this as well. Writing maintainable code is > not > > > just > > > > > > >> about MVVM.
> > > > > > >> >>3) the model never needs to be changed to support changes to > the > > > > > view > > > > > > >> >>4) the viewmodel rarely if ever needs to be changed to > support > > > > > changes > > > > > > >> to the view > > > > > > >> >>5) there can be many views of the same viewmodel
> > > > > > >> Agreed.
> > > > > > >> >>6) the design is as toolable as possible.
> > > > > > >> Do you agree the fact that we need to dump the view as much as > > > > > possible?
> > > > > > > If by "dump" you mean write as little code as possible in the > view, > > > I > > > > > don't > > > > > > > think that is a goal. It *may* be part of the solution, but I > > > think > > > > > the > > > > > > > real thing is to only have code in the view that actually has > to do > > > > > with the > > > > > > > view. Animation code may be huge, but as long as it doesn't > > > include > > > > > > > business logic it is fine in the view.
> > > > > > >> Do you think that using Data Trigger or Value Converter are > > > anti-MVVM? > > > > > If > > > > > > >> yes then what about using Visual State Manager, Blend Behivor, > > > Event > > > > > or > > > > > > >> Property Trigger?
> > > > > > > On the contrary, all those things were created to support the > MVVM > > > > > > > pattern.
> > > > > > >> Is it okay to have control-related stuffs (like Control Event > or > > > etc ) > > > > > in > > > > > > >> View Model?
> > > > > > > No. Then you can't switch what Control (a view thing) you use > > > without > > > > > > > modifying the ViewModel.
> > > > > > >> I'd love to hear other's opinion as well for those > questions.....
Yes you can send a message from the VM to the view. I would definitely do this if there are multiple views of the same VM.
If however there is a 1 to 1 relationship between the View and VM (which is very often the case) I say Yagni. It's much more discoverable, intuitive and more clearly expresses intent to just have an interface for the view. Then instead of sending a message, I just directly invoke it.
I am sure several folks will disagree, so I am ready for you to convince me otherwise :-)
On 2/4/10, Shawn Wildermuth <shawn.li...@agilitrain.com> wrote:
> Let me be clearer, I use commanding (or a Behavior) to talk to the VM and > the VM can issue the message (a la the Messenger in MVVM Light, or > EventAggregator (which is growing too much trouble for me)).
> Note: This was typed on a big ole laptop so any misspellings and > punctuations are completely my fault.not my phone's.
> From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] > On Behalf Of Jeremiah Morrill > Sent: Thursday, February 04, 2010 6:29 PM > To: wpf-disciples@googlegroups.com > Subject: Re: [WPF Disciples] Re: MVVM Questions
>>>I try to avoid the ViewModel knowing about the view via an interface > if at all possible
> +1 Daniel. Though I try to avoid the event aggregator if the event needs to > be published from the View, like in the case of IActiveAware. In that > scenario I might go into a cheaper/lazy MVP style by opening up the > IViewModel with an IViewModel.SetActive(...) and storing ref to IViewModel > on my IView.SetViewModel(...).
> On Thu, Feb 4, 2010 at 3:04 PM, Daniel Vaughan <dbvaug...@gmail.com> wrote:
> I try to avoid the ViewModel knowing about the view via an interface > if at all possible, preferring instead loosely coupled eventing (as in > Prisms). I see this a being 'pure' MVVM, and sometimes it may not be > practical. > I'd say that in non-arbitrary projects, the message service is better > implemented as a service, as I think most of us do anyway.
> On Feb 3, 5:38 pm, Michael Sync <mchls...@gmail.com> wrote: >> Thanks a lot, John. I'm really appreciate it.
>> What about if you and our WPF/Silverlight community create a standard for >> MVVM pattern? I understand that there are a lot of way to implement MVVM > but >> at least, there are some obvious rules that everyone can follow so > everyone >> has same understanding about that pattern.
>> Here are some of my thoughts.
>> *Goals*
>> - >> - Testabiltiy ( ViewModel is easier to unit test than code-behind or >> event driven code) >> - Clear seperation between UX designer and developer >> - Increases the "Blendability" of your view >> - Model never needs to be changed to support changes to the view >> - ViewModel rarely needs to be changed to support changes to the view >> - No duplicated code to update views
>> *Do and Don't in View*
>> - *shouldn't contain any logic that you want to test* : As Glenn said >> that MVVM is not code counting exercise, we can write code in > code-behind. >> But you should never write any logic that you want to test. For > example: If >> user select a country then you want to display the list of states or > city in >> your view. This is the business requirement so you should have unit > test to >> test this logic. So, you shouldn't write it in code-behind. >> - *can be a user control or Data Template* >> - *Keep the view as simple as possible. : *We can still use Data > Trigger >> or Value Converter or Visual State or Blend Behivor in XAML with care. >> - *use attached property if something is not bindable : *There is one >> common mistake about PasswordBox. We all knows that WPF Password is not >> bindable due to the security reason. But if you are having a string > property >> "Password" in Model then it won't be secure no matter whether you set > it >> from code-behind or attached property.
>> *Do and Don't in ViewModel*
>> - An abstraction of View >> - Connector between View and Model >> - Keep View State, Value Conversion >> - No strong or weak (via Interface) reference of View >> - Make VM as testable as possible (e.g. no call to Singleton class) >> - No Control related Stuff in VM ( Because if you are changing the view >> then you will have to change VM as well. )
>> *Model *
>> - >> - can be Data Model, DTO, POCO, auto-generated proxy of domain class > and >> UI Model based on how you want to have the separation between Domain > Service >> and Presentation Layer >> - No reference to ViewModel
>> Thanks and Best Regards, >> Michael Sync
>> Don't go the way life takes you. >> Take life the way you go
>> On Wed, Feb 3, 2010 at 11:56 PM, John Gossman <gossmans...@gmail.com> > wrote:
>> > On Tue, Feb 2, 2010 at 11:13 PM, Michael Sync <mchls...@gmail.com> > wrote:
>> >> Hi John,
>> >> Thanks for creating MVVM pattern. :)
>> > To be clear...I didn't actually create it, I learned it from some > Smalltalk >> > devs and figured out how to use it with WPF...but you're welcome. :-)
>> >> >>1) efficiently write rich UI
>> >> I agree that we can use MVVM to write rich UI efficiently. But I don't >> >> think that MVVM is the only way to write rich UI efficiently. There are > a >> >> lot of patterns that we can write rich UI ( UI is not just > WPF/Silverlight)
>> > I didn't say it was the only way. All I said was one of the goals of > MVVM >> > was to write UI efficiently.
>> >> >>2) where the code is maintainable
>> >> The same goes for this as well. Writing maintainable code is not just >> >> about MVVM.
>> >> >>3) the model never needs to be changed to support changes to the view >> >> >>4) the viewmodel rarely if ever needs to be changed to support > changes >> >> to the view >> >> >>5) there can be many views of the same viewmodel
>> >> Agreed.
>> >> >>6) the design is as toolable as possible.
>> >> Do you agree the fact that we need to dump the view as much as > possible?
>> > If by "dump" you mean write as little code as possible in the view, I > don't >> > think that is a goal. It *may* be part of the solution, but I think the >> > real thing is to only have code in the view that actually has to do with > the >> > view. Animation code may be huge, but as long as it doesn't include >> > business logic it is fine in the view.
>> >> Do you think that using Data Trigger or Value Converter are anti-MVVM? > If >> >> yes then what about using Visual State Manager, Blend Behivor, Event or >> >> Property Trigger?
>> > On the contrary, all those things were created to support the MVVM >> > pattern.
>> >> Is it okay to have control-related stuffs (like Control Event or etc ) > in >> >> View Model?
>> > No. Then you can't switch what Control (a view thing) you use without >> > modifying the ViewModel.
>> >> I'd love to hear other's opinion as well for those questions.....
>> >> Regards, >> >> Michael Sync
>> >> Don't go the way life takes you. >> >> Take life the way you go
>> >> On Tue, Feb 2, 2010 at 3:09 AM, John Gossman > <gossmans...@gmail.com>wrote:
>> >>> I haven't written anything about MVVM in a while because there is so > much >> >>> material already being published. However I have been thinking about > what >> >>> we can do in the platform to make things better and reading a lot of > the >> >>> public stuff, so I thought I'd summarize for my own sake if nothing > else:
>> >>> The state of MVVM reminds me of Peter Naur's classic paper > "Programming >> >>> as Theory Building". He basically says the proper model for computer >> >>> programming is not engineering but scientific development where you > have >> >>> problem, you develop a hypothesis for how to fix it, you experiment > (write >> >>> code and test it), and then you decide whether you've solved the > problem. >> >>> If not you synthesize a new hypothesis and try again.
>> >>> MVVM feels more like "science" than anything else I've seen...with > lots >> >>> of authors publishing papers containing their hypotheses and results > and >> >>> suggesting avenues for further research. Some papers are better than >> >>> others, some are revolutionary and some contain nothing new.
>> >>> Fundamentally I think the goal of MVVM has still not been clearly >> >>> stated. I posit some of the goals include: >> >>> 1) efficiently write rich UI >> >>> 2) where the code is maintainable >> >>> 3) the model never needs to be changed to support changes to the view >> >>> 4) the viewmodel rarely if ever needs to be changed to support changes > to >> >>> the view >> >>> 5) there can be many views of the same viewmodel >> >>> 6) the design is as toolable as possible.
>> >>> To my mind #6 is the most important and perhaps the one we still have >> >>> made the least progress with. Blend Behaviors are a huge step in the > right >> >>> direction, but we need to go further.
>> >>> I don't think eliminating all code from the View is part of the goal, >> >>> though it obviously makes some of the others easier. When it makes > them >> >>> harder though, one should write view code (though whether that means > the >> >>> code behind model or something else is not clear).
>> >>> Among the next steps, I would like to eliminate the boilerplate code > for >> >>> INotifyPropertyChanged (and eventually eliminate DependencyProperties > and >> >>> DependencyObjects and allow any property on any class to support > binding and >> >>> change notification). Further I would like to bind events in the View >> >>> directly to Commands on the ViewModel so you can say <Button > Click="{Binding >> >>> SaveCommand}" MouseRightButtonUp="{Binding
Where is that rule written that 'Thine ViewModel must not reference thy view'? The pattern of MVVM (which is very similar to PresentationModel) is all about the encapsulation of the View logic in the model, and about the View talking to it through binding. It sets no constraints on how the VM talks back to the biw.
On 2/4/10, Michael D. Brown <mike.br...@azurecoding.net> wrote:
> I agree with the good doctor on this. It doesn't matter if it's ViewModel or > Presenter it's all poo. In the strictest sense, a viewmodel shouldn't have a > reference to a given view.but that guidance is there because should you need > it a ViewModel can be reused with multiple views (you could even go so far > as having a ViewModel support multiple UI platforms such as WPF/Silverlight > and even ASP.NET MVC). If you don't need this capability, ignore that > guidance and put what you need into the VM. Just don't go hog wild and > consider using interfaces to remove coupling to a SPECIFIC view. Both of > these will open options for you in the future to support multiple views and > possible even different platforms.
> From: wpf-disciples@googlegroups.com [mailto:wpf-disciples@googlegroups.com] > On Behalf Of Michael Sync > Sent: Wednesday, February 03, 2010 9:52 PM > To: wpf-disciples@googlegroups.com > Subject: Re: [WPF Disciples] Re: MVVM Questions
> interface IView{
> void ShowMessage(string message);
> }
> class View : IView {
> public void ShowMessage(string message){
> MessageBox.Show(this, message);
> }
> }
> class ViewModel{
> private IView view;
> public ViewModel(IVew view){
> this.view = view;
> }
> ........
> view.ShowMessage("This is a msg");
> }
>>>>To some extent, that's a good thing. MVVM is a pattern. Patterns can be > applied in multiple ways. As long as the pattern is still adhered to, the > differing applications are not really relevant. Things like "not having any > reference to the View from the ViewModel" are not part of the pattern.
> This is what you believe, right? There are a lot of people who believe that > VM should not have any view reference. According to John's class diagram > <link <http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx> >, > the 2-ways binding is the only way that we communicate between View and > ViewModel. Not via interface.
> I believe that "not having any reference to the View from the ViewModel" can > be a part of pattern because we don't want VM to be changed to support the > changes of View.
> Actually, pattern has a name. The way of implementing the pattern can be > different and we can combine a few patterns together based on our need. But > still it has a name.
