Mvvm in the real world tccc10

Notas del editor

1. http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspxWhen implemented on a class,INotifyPropertyChanged allows you to notify consumers about changes in the values of your properties by raising the PropertyChanged event. The PropertyChangedEventHandler takes the sender (instance raising the event) and PropertyChangedEventArgs (adds [string PropertyName] to the standard EventArgs) as arguments.
2. http://msdn.microsoft.com/en-us/library/system.collections.specialized.inotifycollectionchanged.aspxWhen implemented on a class (almost always a collection),INotifyCollectionChanged allows it to notify consumers that the collection has changed by raising the CollectionChanged event. The event arguments specify how the collection changed (NotifyCollectionChangedAction) and the items that changed.Add – Item(s) were addedRemove – Item(s) were removedReplace – One item was exchanged for another. I.e. say x[3] = Foo; if I then say x[3] = Bar; the object (Foo) at index 3 is replaced (with Bar)Move – An objects was moved to a different index, e.g. collection was sorted, the object at index 3 was moved to index 5.Reset – A large change has happened to the collection and anything watching it should just reinitialize. Most commonly happens when the Clear() method is called.
3. http://msdn.microsoft.com/en-us/library/ms750612.aspxDataBinding allows two properties (as long as one is a DependencyProperty, discussed later) to have their values stay synced up.
4. Value converters (classes that implement IValueConverter and/or IMultiValueConverter) are used to convert values from value to another. Frequently used in data binding where the two properties have a known relationship but not necessarily the same value. For instance I might convert a booleantrue into Visibility.Visible and false into Visibility.Collapsed.
5. http://msdn.microsoft.com/en-us/library/system.windows.dependencyproperty.aspx
6. A User Control allows you to group a set of visual elements into a single unit and gives you a code behind file, allowing you to add custom dependency properties. If you are not going to have any code behind in your User Control it’s usually better to use a DataTemplate instead which basically functions as a User Control without the code behind.
7. Command Pattern = a design pattern where an object is used to represent and encapsulate all the information needed to call a method at a later timeDelegateCommand overview - http://kentb.blogspot.com/2009/04/mvvm-infrastructure-delegatecommand.html
8. Blend/Visual studio workflow is really a goal of MVVM rather than the more general Presentation Model pattern. However use of a Presentation Model pattern will tend increase the separation of designer and developer allowing them to work without stepping on each other’s toes.
9. See http://martinfowler.com/eaaDev/PresentationModel.html
10. The highlighted portions of each pattern are their “Presentation Model”, this is where the real differences in the patterns reside and is often the most difficult layer to get right.
11. The model is/should be exactly the same across all of the presentation model patterns and many other architectural patterns allowing you to share it among applications if necessary.
12. The View Model is the hardest layer to get right in MVVM. Most people when first using the pattern will try to make the View Models either be a code behind for the view or a façade/adapter for the model. Neither is correct. We go over some of the warning signs and how to shift your approach throughout the presentation.
13. The interface to the user. Shouldn’t contain much in the way of code or logic other than what’s necessary to display data.
14. Your unit tests will tell you very early if your View Model is starting to become too tightly coupled to a particular View or Model.
15. Check Wikipedia or one of a hundred blog posts for a more in-depth explanation.
16. The one thing to remember is to choose one and stick with it.
17. Most talks and blog posts about MVVM claim you should have no code in the View. That’s mostly true but there are a few times when you won’t be able to avoid it.
18. Think of it as technical debt with a low interest rate. Not to be taken on lightly, but a better choice than some other areas.
19. Use them wherever necessary but they can let others do stupid things if put into the Model so consider what people will do in the future with the extra power before putting them in the model.
20. These are the issues I’ve seen pop up the most often. If you’ve run into other general issues I’d like to hear about them. Feel free to send me an email at bryan.anderson@ilmservice.com
21. Fluffy represents both, your users who are annoyed that you popped up a message box on them, and your fellow developers annoyed that unit tests no long run unattended because they have to click OK on a message box. You’ve been warned.
22. There are many ways to display an error/warning/notification in the user interface without resorting to a message box. I personally like the way www.stackoverflow.com does it but you could also do something like a browser’s status bar or use adorners.
23. This is the page I recommended searching for http://marlongrech.wordpress.com/2008/12/13/attachedcommandbehavior-v2-aka-acb/
24. Code behind is a lot like a goto, you might not think it will cause a problem but you should check for lurking raptors first.
25. It really just comes down to logic and experience. Ask yourself if a certain portion would change if you changed the way you’re presenting the information in the view. If it would it probably belongs in the view.
26. I tend to lean toward using the command parameter more often than not because it tends to have fewer side effects and I think it presents a more consistent interface to consumers of the view model. However, many people favor an extra property because they find that it’s easier to understand what the value is and where it comes from.
27. Don’t think of MVVM as sets of M, V, and VM running around as triples. There is a many-to-many relationship among all of them even if they sometimes pretend it’s a one-to-one.The single responsibility principle comes into play here especially in the View Model, follow it and a lot of your issues will go away.
28. I’d love to hear feedback on the talk and/or these slides (both positive and negative). Please don’t hesitate to let me know what you thought.