Jason Rainwater posted a nice summary of the ways in which you can hook up the View and the ViewModel:

May 26

MVVM, providing the Association of View to ViewModel

Hello everyone!

As stated in my previous post, today I will be talking about the different ways we can associate a ViewModel (or any other type of middle object in the MV? design patterns) to the View.

When we look at the UI design patterns we almost always have a View and a middle object, whether it be a ViewModel, Presenter, Controller, Presentation Model, or other newly thought up facilitators, their has to be some sort of association between them.  Today I will show two different ways that we can associate a View to a ViewModel.

The first is my personal favorite and that is using a DataTemplate.  A DataTemplate is a way we can provide a visual representation of any object.  The object in our case is the ViewModel.

   1: <DataTemplate DataType="{x:Type vms:PersonViewModel}">

   2:     <vws:PersonView />

   3: </DataTemplate>

What this does is allows us to use a ViewModel as content and have it resolve the PersonView as the visual to be used.  The cool thing about this is that because the View is the representation of the DataTemplate the View will automatically have a DataContext set to the ViewModel that was set as Content.  So inside the View we can <TextBlock Text="{Binding PersonModel.FirstName}"/> and the binding will work.  This to me is the way to keep the most separation of visuals and behavior.  The View knows nothing directly about the ViewModel and the ViewModel knows nothing directly about the View.  If you create a new View you can just inject a new DataTemplate targeted to the same type and you will have a new Visual for your ViewModel.

The drawback to this is that you do have a full separation so if you need a few coupled items you may have to utilize some other concepts or break the separation by having references back and forth between the View and ViewModel.

The second way to provide the association is using Constructor Injection to the ViewModel and instance of the View.  The code may look something like this.

   1: public class PersonViewModel

   2: {

   3:     private IPersonView _view;

   4:  

   5:     public IPersonView View

   6:     {

   7:         get

   8:         {

   9:             return _view;

  10:         }

  11:     }

  12:  

  13:     public PersonViewModel(IPersonView view)

  14:     {

  15:         _view = view;

  16:  

  17:         _view.DataContext = this;

  18:     }

  19: }

What this does is allows the ViewModel to contain an instance of the View so that it can do things like utilizing events to it, making method calls and such.  The way we would utilize this is by using either concrete instantiation or Dependency Injection resolution.

   1: PersonViewModel viewModel = UnityContainer.Resolve<PersonViewModel>();

   2:  

   3: NavigationManager.NavigateTo(viewModel.View);

Whichever view is registered with the container is the View that will get used so we can still provide different Views for the same ViewModel in this case.  This gives us more access to things on the View but also tightly couples us a little more.  This is not a bad thing but it may be too much for your needs depending on the project.  This also "looks" more like a Presenter than a ViewModel at this point.

The key to the semantics of these different interactions is the difference between a ViewModel and a Presenter.  Generally the second way looks more like a Presenter, but we call is a ViewModel.  I do not think it really matters what we call it as long as certain guidelines are followed.  Things like using Binding.  We can call it a Controller with Binding if we want as along as we adhere to utilizing Binding.

I hope this information is useful and have a good day!

For me, the keyboard is paramount and the mouse should only used as a last resort.  It is in direct alignment with my contention that the command line is paramount and a GUI should be used only as a last resort.  Perhaps juxtapose to those postulates is the fact that i *love* the NUI.  At any rate, i became interested in Accessibility primarily because keyboard shortcuts/hotkeys/accelerators allow me to keep my distance from the mouse.  In HTML5 investigations i ran across John Foliot who runs the Stanford Online Accessibility Program.  On the SOAP home page i found an analogy that became a metaphor for my own experience with Accessibility. 

"A simple analogy is sidewalk cut-curbs. Initially provided to assist users in wheel-chairs, cut curbs today also benefit people on roller-blades and skate boards, cyclists and mothers with baby strollers; user-groups never originally envisioned when cut-curbs were first mandated. And while retro-fitting older sidewalk intersections was a time consuming and expensive undertaking, today the inclusion of cut-curbs in new sidewalk construction is a matter of course, and adds little to nothing to the overall cost of sidewalk construction or repair."

i'm a user that can, but doesn't want to use the mouse; i'm in a user-group probably never originally envisioned by the good folks that championed and those that continue to fight for Universal Accessibility.

PInvoke should be used sparingly; there should be a managed API for almost everything you want to do.  However, sometimes you absolutely have to talk to the unmanaged world from your comfy managed world.  Not using it often is not an excuse for not knowing about it.  First, who knows what problems you may run into that could only be solved by invoking some platform API.  Moreover, the more you know, the more you know.broadening your understanding of programming concepts is obviously advantageous to a developer.blah, blah, blah learning's good, mmmkay.  Recently i was prototyping some functionality using the GetStringScripts API and ran into some issues with out parameters.

MSDN defines the syntax for this unmanaged function as the following.

   1:  int GetStringScripts(

   2:    __in   DWORD dwFlags,

   3:    __in   LPCWSTR lpString,

   4:    __in   int cchString,

   5:    __out  LPWSTR lpScripts,

   6:    __in   int cchScripts

   7:  );

When i saw the __out LPWSTR lpScripts parameter, i erroneously assumed that i should use the C# out keyword.  i was getting Access Violation errors until i was wised up by some site i found.  i hacked fixed up the code according to the example i saw and everything worked fine.  Left ill at ease, i decided to investigate more deeply.  i found myself asking, "How do you know how to properly write PInvoke signatures?"  PInvoke.net is "primarily a wiki, allowing developers to find, edit and add PInvoke signatures, user-defined types, and any other information related to calling Win32 and other unmanaged APIs from managed code" but that's me doing copy-and-paste hacking-that's not me understanding what i'm doing.

   1:          [DllImport("kernel32.dll",

   2:                      EntryPoint="GetStringScripts",

   3:                      SetLastError= true,

   4:                      CharSet = CharSet.Unicode,

   5:                      ExactSpelling=true,

   6:                      BestFitMapping=false,

   7:                      ThrowOnUnmappableChar=true,

   8:                      CallingConvention = CallingConvention.StdCall)]

   9:          public static extern int GetStringScriptsImport(

  10:              uint dwFlags,

  11:              [In, MarshalAs(UnmanagedType.LPWStr)] String lpString,

  12:              int cchString,

  13:              [Out, MarshalAs(UnmanagedType.LPWStr)] String lpScripts,

  14:              int cchScripts);

C# syntax only allows for DllImport, while Visual Basic allows for the declare statement and for the DllImport.  While blittable types were a new one on me, my investigation is going to stop shorter than i had originally guessed.  The real information that i care about is captured in msdn articles on Platform Invoke Data Types, Marshaling Arguments, and the DllImportAttribute Class which defines how to deal with complex method definitions that include BestFitMapping, CallingConvention, ExactSpelling, PreserveSig, SetLastError, or ThrowOnUnmappableChar fields.  And if i ever need to do some more Platform Invocations, i'll look to the Platform Invoke Tutorial.

Background Reading:

Blittable/Non-Blittable Types

Broad definition

A memory copy operation is sometimes referred to as a 'block transfer'. This term is sometimes abbreviated as BLT (there's actually a BLT instruction on the PDP-10) and pronounced 'blit'. The term 'blittable' expresses whether it is legal to copy an object using a block transfer.

Pasted from <https://en.wikipedia.org/wiki/Blittable_types>

.NET framework context

Blittable and Non-Blittable Types

Most data types have a common representation in both managed and unmanaged memory and do not require special handling by the interop marshaler. These types are called blittable types because they do not require conversion when they are passed between managed and unmanaged code.

Return values from platform invoke calls must be blittable types. Platform invoke does not support non-blittable return types.

The following types from the System namespace are blittable types:

• System.Byte

• System.SByte

• System.Int16

• System.UInt16

• System.Int32

• System.UInt32

• System.Int64

• System.UInt64

• System.IntPtr

• System.UIntPtr

• System.Single

• System.Double

The following complex types are also blittable types:

• One-dimensional arrays of blittable types, such as an array of integers. However, a type that contains a variable array of blittable types is not itself blittable.

• Formatted value types that contain only blittable types (and classes if they are marshaled as formatted types). For more information about formatted value types, see Default Marshaling for Value Types.

Object references are not blittable. This includes an array of references to objects that are blittable by themselves. For example, you can define a structure that is blittable, but you cannot define a blittable type that contains an array of references to those structures.

As an optimization, arrays of blittable types and classes that contain only blittable members are pinned instead of copied during marshaling. These types can appear to be marshaled as In/Out parameters when the caller and callee are in the same apartment. However, these types are actually marshaled as In parameters, and you must apply the InAttribute and OutAttribute attributes if you want to marshal the argument as an In/Out parameter.

Some managed data types require a different representation in an unmanaged environment. These non-blittable data types must be converted into a form that can be marshaled. For example, managed strings are non-blittable types because they must be converted into string objects before they can be marshaled.

The following table lists non-blittable types from the System namespace. Delegates, which are data structures that refer to a static method or to a class instance, are also non-blittable.

Non-blittable type

Description

System.Array

Converts to a C-style array or a SAFEARRAY.

System.Boolean

Converts to a 1, 2, or 4-byte value with true as 1 or -1.

System.Char

Converts to a Unicode or ANSI character.

System.Class

Converts to a class interface.

System.Object

Converts to a variant or an interface.

System.Mdarray

Converts to a C-style array or a SAFEARRAY.

System.String

Converts to a string terminating in a null reference or to a BSTR.

System.Valuetype

Converts to a structure with a fixed memory layout.

System.Szarray

Converts to a C-style array or a SAFEARRAY.

Class and object types are supported only by COM interop. For corresponding types in Visual Basic 2005, C#, and C++, see the .NET Framework Class Library Overview.

See Also

---

Other Resources

Default Marshaling Behavior

 

Pasted from https://msdn.microsoft.com/en-us/library/75dwhxf7.aspx

OutAttribute

The OutAttribute is optional. The attribute is supported for COM interop and platform invoke only. In the absence of explicit settings, the interop marshaler assumes rules based on the parameter type, whether the parameter is passed by reference or by value, and whether the type is blittable or non-blittable. For example, the StringBuilder class is always assumed to be In/Out and an array of strings passed by value is assumed to be In.

Out-only behavior is never a default marshaling behavior for parameters. You can apply the OutAttribute to value and reference types passed by reference to change In/Out behavior to Out-only behavior, which is equivalent to using the out keyword in C#. For example, arrays passed by value, marshaled as In-only parameters by default, can be changed to Out-only. However, the behavior does not always provide expected semantics when the types include all-blittable elements or fields because the interop marshaler uses pinning. If you do not care about passing data into the callee, Out-only marshaling can provide better performance for non-blittable types.

Combining the InAttribute and OutAttribute is particularly useful when applied to arrays and formatted, non-blittable types. Callers see the changes a callee makes to these types only when you apply both attributes. Since these types require copying during marshaling, you can use InAttribute and OutAttribute to reduce unnecessary copies.

Pasted from <https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.outattribute.aspx>

Alexander Biskop's venting session scrutinizes, as opposed to only evangelizing, the pattern à la mode.  Biskop's primary charge is aligned with the MVVM sample applications i've seen thus far-they are usually some variation of a form-based record editing application.

"MVVM is an *awesome* template for record editing applications and simple projects, but I would *never* recommend it for a large-scale application."

In the remainder of the forum based rant, Biskop cites and discuses points from the MVVM article on Wikipedia.

"There are currently three main areas of criticism regarding the MVVM pattern.

The first is that MVVM currently lacks standardization from Microsoft both in implementation and in toolsets. For example, the community has some lack of clarity about where and whether to implement View logic in the View layer or the ViewModel. Given that the MVVM pattern is still relatively new, and that new tool-sets, walkthroughs, or patterns, such as Onyx, the Microsoft WPF Toolkit, Caliburn, MVVM Light Toolkit, and Calcium are being released, this problem may be solved over time. Microsoft has announced in discussion boards that the MVVM template pattern will be released in Visual Studio 2010.

The second comes from MVVM creator John Gossman himself ^[8], who points out that the overhead in implementing MVVM is "overkill" for simple UI operations. He also states that for larger applications, generalizing the View layer becomes more difficult. Moreover, he illustrates that data binding, if not managed well, can result in considerable memory consumption in an application.

The third is that the exercise in creating large numbers of data bindings to the ViewModel results in duplicate code and maintenance problems^[9]. Additionally, because of the nature of the semantics of data bindings, critics suggest that the ViewModel does not directly describe the View."

Biskop's post reminded me to examine when and where MVVM should and shouldn't be used.  Thanks, Mr. Biskop!

"Core Concept #2 Don't Look Up. We tend to conceptualize the View (User Interface objects) at the top, the ViewModel (objects that provide the UI with its data and behaviors) in the middle and the model (often the persistence layer) at the bottom. The View can know about the ViewModel, the ViewModel about the Model, and the Model, like the cheese, stands alone."

There is intentionally/explicitly NOT a red arrow from the View all the way down to the Model .  Also of note is the fact that the arrows are not bidirectional-this underscores the fact that the View knows about the ViewModel and that the ViewModel knows about the Model, but NOT any combination of the reverse.  When a field in the ViewModel has been bound to something in the View, the ViewModel is not specifically telling that particular View that the field has changed; instead, generically, the ViewModel's field is changed and the ViewModel notifies subscribers of the change.

WPF Review/MVVM Intro

XAML based layout flow and user interaction event definition; they do some nice painting and rendering performance for you.

"It was once commonly said that all roads lead to Rome. Today all WPF and Silverlight best practices lead to the Model-View-ViewModel design pattern."

This is great because it alludes to the fact that it's not just Silverlight that does all this XAML sugary goodness, it was WPF first, and now Silverlight. When asked if Silverlight is the death of WPF, most Silverlight evangelists chime in with, "(paraphrase:) Silverlight's the best thing to happen to WPF; Silverlight doesn't kill WPF, it brings a technology that's been in the industry now for a few years back under a fresh spotlight."

"The fundamental mechanisms involved in creating applications based on MVVM are data binding and commands. ViewModel objects expose properties to which Views are bound, including properties that return command objects. When the properties of a ViewModel change, the Views bound to that ViewModel receive a notification when the ViewModel raises its PropertyChanged event (which is the sole member of the INotifyPropertyChanged interface). The data binding system will automatically get the new value from the modified property and update the bound properties in the View. Similarly, changes made to the data in the View are pushed back to the ViewModel via bindings. When the user clicks on a button whose Command property is bound to a command exposed by a ViewModel, that command executes and allows the ViewModel to act on the user's interaction. If the ViewModel needs to expose a modifiable collection of objects to a View, the ViewModel can use ObservableCollection<T> to get collection change notifications for free (which the binding system knows how to work with). It's all very simple to implement because data bindings do the grunt work of moving bound data values around when necessary.

The magic glue that ties Views and ViewModels together is, more often than not, the DataContext property inherited by all visual elements. When a View is created, its DataContext can be set to a ViewModel so that all elements in the View can easily bind to it. This is not a hard and fast rule, though. Some people prefer to put their ViewModels into resource dictionaries and bind to them via resource references. That technique can make it easier to work with Views in Microsoft's Expression Blend visual design tool."

Best practices for designing Views

"Advanced MVVM" mentions the Mole visualizer which is nice for inspecting the "visual tree" of a piece of UI.

"In non-trivial user interfaces there are various bits of code required to make a View work properly. If that code relies on UI elements, resources, or anything else belonging to the realm of the user interface, I see no reason not to put that code into the View's code-behind."

Best practices for designing ViewModels

Each View class should have a corresponding ViewModel class; the View's DataContext is set to its ViewModel object. Views should reference ViewModels from a separate project/assembly. The MVVM Foundation library on CodePlex "contains several useful classes for developers writing ViewModels. The MVVM Foundation classes used in this application are ObservableObject and RelayCommand."

Rather creating and assigning the ViewModel in the View code-behind, XAML can also handle declaration and assignment for the DataContext/ViewModel.

   1:  <UserControl.DataContext>    

   2:      <viewModels:FooViewModel/>

   3:  </UserControl.DataContext>

"WPF requires collection change notifications to occur on the UI thread."

"DataTriggers in the View layer bind to that property in order to turn on/off visual effects for the bubble group under the cursor. You can see how that works by looking at the Style whose x:Key is 'BubbleGridStyle' in the BubbleViewResources.xaml file, if you re interested."

Deciding on what state and logic belongs in Views versus ViewModels

"[L]imiting your Views to only the code that is specific to their events, elements, resources, etc. enables you to keep the various application layers clear, logical, and loosely coupled. Separation of concerns is a worthwhile goal when writing software."

Coordinating animated transitions and unlimited undo between the ViewModel and View

"When pending tasks are made available, three methods work together to process them and perform animated transitions. These methods are in the code-behind of [the View]"

The Unit of Work pattern is an elegant solution for animation precipitating input timing issues; this task-based architecture lends itself well to animated transitions between tasks and ease of unlimited undo functionality.

Path seems to flip X coordinate space automatically based on FlowDirection. at least in WPF 3.5. (I didn't have SL4 handy.) There's no reason I know of for SL4 runtime to break compat with WPF on this, so I expect SL4 is the same.

This XAML:

<Grid FlowDirection="LeftToRight">

<Button Margin="100,0,0,0" Content="Has 'Before' Margin"/>

<Path Stroke="Black" HorizontalAlignment="Left" Data="M58,47 L34,85 L59,120 L58,93 L115,90 L113,72 L59,70 z"/>

</Grid>

Yields a button with left-side margin, and path rendered as I expected (it's an arrow pointing left.)

Change FlowDirection to RightToLeft and you get right-side margin, arrow pointing right. This is all correct for RTL.

Wade

Behavior in a mixed environment for Bidi and non-Bidi text

When dealing with Bidi text, there are two settings to consider - text alignment and text direction, which are independent of each other.

Text Alignment

For text alignment, whether the text should be left or right aligned could depend on either the control's property, user or application language settings, language of the first character, or other settings; it can also be a combination of any of these. The inconsistency among Bidi text alignment is an Office wide issue, because there's no absolute correct behavior.  It would be the best if options of choosing the alignment are provided to the user.  When no options are available, each situation can be different, and using the surrounding layout as a reference would be a good starting point.

For example, in the screenshot below, user 1 is using Arabic version of Communicator while user 2 is using the English version.  The message sent by user 1 is right aligned, while the message from user 2 is left aligned.  In this case, since user 1 is in a right-to-left environment and the names were aligned to the right, it would probably have been easier for the user to read all the messages if they were all right aligned regardless of the language of the text. 

Text Direction

Text direction is more important than alignment, since it can affect the meaning of the text.  In the worst case, text can become unreadable.  There are three types of text direction, Left-To-Right, Context, and Right-To-Left.  Below is an example from Outlook options.  Some applications don't have support for Context text direction. 

Again, don't confuse this with text alignment, as it's possible that each of these text direction can coexist with both left or right text alignment.  When only Bidi (i.e. Arabic) text are entered by themselves, the text will stream from right to left regardless of the text direction setting, vice versa for or non-Bidi (i.e. English) text, this means the caret will always appear on the left when Arabic is being entered and on the right when English is entered.  Here are the differences between each setting, which are also the expected behaviors.

Left-To-Right

When HOME key is pressed, caret will always appear at the leftmost position.  In certain applications like Outlook, when a neutral character (space, most punctuation, numerals, etc.) is entered, the caret will go to the right of current input sequence.  If you are entering Arabic text, which goes from right to left, you'll see the caret jumps to the right when you enter a space, and then jumps back to left when you continue to type in Arabic. It's not a bug whether the caret jumps or not.

Right-To-Left

When HOME key is pressed, caret will always appear at the rightmost position.  In certain applications like Outlook, when a neutral character (space, most punctuations, numerals, etc.) is entered, the caret will go to the left of current input sequence.  If you are entering English text, which goes from left to right, you'll see the caret jumps to the left when you enter a space, and then jumps back to right when you continue to type in English.  Again it's not a bug whether the caret jumps or not.

Context 

Context text direction will behave just like Left-To-Right or Right-To-Left depending on the first non-neutral character entered. If the character is Bidi, then the text direction will become Right-To-Left for the control, and If the character is non-Bidi, then the text direction will become Left-To-Right for the control.

Behavior when mixing with neutral characters in Bidi environment

One of the common issues with Bidi environment is the unexpected behavior when mixing with neutral characters. Shown below are examples of forward slashes mixing with URL name containing Bidi text and ellipsis showing on the wrong side of the abbreviated English text.  The first bug is more severe since it's hard for the user to read the URL.

There are a few approaches to fix the issues.

First approach is changing the text direction property in the control if viable.  For the first bug, Left-To-Right would be the best since we want the forward slashes in left to right direction regardless of the text surrounding them.  For the second bug, Context would be the best since the ellipsis would show in the correct position for both English and Arabic text. 

For cases like the second bug, which is a SharePoint page with HTML language and doesn't have the Context option, it's recommended to use the dir="ltr|rtl" HTML attribute to define embedded direction changes.  For example, the below <span dir="ltr"> markup renders the "." string truncation ellipsis to the right -- "Product Ca.", even though it's within a "rtl" body.

<body dir="rtl">

    some text

    <span dir="ltr">Product Ca.</span>
</body>

Another approach, the last resort, the costly and dangerous way, don't do it unless you are absolutely sure that the text will always be non-Bidi text or always be Bidi text, is to use override characters.  We can insert a Left-To-Right override (U+202D) character in the beginning of the English text to force the ellipsis to show on the right, vice versa for Bidi text using the Right-To-Left override (U+202E) character.    The override will affect not just the direction of the words, but individual letters as well.  So "hello world" would become "dlrow olleh" if the Right-To-Left override character is inserted before the text.

Another colleague tells me to "check out Nikhil Kothari's MIX'10 presentation. . .there's some WCF RIA Services stuff as it works with MVVM. . .interesting."  He was right: it's a beautiful bright future for RIAs; this illustrates one aspect of why and more importantly how.  Developers will be able to rapidly deploy applications in an extremely well patterned manner.  When i say developers, i'm referring to both developers internal to and external to Microsoft Corporation.  This has direct implications on Silverlight for Windows Phone 7 Series RIAs.  I think that we're posing ourselves nicely for competition with iPhone.  Personally, i'd kill to not have to write an iPhone App.  i can't stand their developer experience; It's horrible.  Between Expression Blend, MVVM, Visual Studio 2010, and a hundred other reasons, i'd love to pursue the possibility of switching from the iPhone.

ViewModel, RIA Services, and MEF Vision

• Separating your UI from your interesting Application Logic.
• Facilitate Designers and Developers working together.
• Encapsulates the state and operations of your application.
• Improve maintainability
• Facilitate testability

xmlns:local="clr-namespace:SDKSample"
 

https://blogs.msdn.com/unnir/archive/2009/07/12/introducing-sample-data-for-developers.aspx

View: Presentation logic--XAML, UI Logic in the code-behind. In the XAML you define a d:DataContext (the design time data context) to the appropriate Type attribute value (and a flag for IsDesignTimeCreatable) lets the IDE know about what types of Properties and Methods so that the data binding picker works.

The IDE properties pane for the UI Element allows you to set the ItemSource; the presented options are Properties off of the d:DataContext Type definition. An alternative to handling Command Operation to Method Invocation mappings, by configuring Methods in the ViewModel using ICommandProperties Attributes, is to define such mappings in the Page Resources definitions in the View XAML. Once you have those definitions in the View XAML, the IDE allows the Page resource to apply Command operations as a resource in the Properties pane of the IDE. The CommandParameters attribute in the Properties pane can be bound to the another UI element, allowing the Command (Method Invoke) to take in parameters.

View Model: App State, Operations, Change Notifications. Any class that implements INotifyPropertyChanged can serve as a View Model, Nikhil demonstrated that he uses ViewModelBase. An Instance of the View Model serves as the DataContext for your UI/View, (hooked up immediately following initialization of the View); this is more or less a refactoring, more like obsolescence, of the code-behind file for the View.

States and Operations map to the ViewModel Class Methods and Properties.

Data Model and MEF: Services, Business Rules. RIA Services detects from your Data Model Class Attribute definitions for, optionally custom, validation rules. This partial, server side shared code, gets propagated to the client along with metadata intent for the validation rules. The Model Entity Framework handles propagating that server side validation rule to the client generated code stubs. Database field constraints in the schema (VARCHAR(10)) can cause these validation rules to show up in the client stub also. This constitutes client side validation. You're going to add other validations that can only be run server side. The ability to explicitly configure CRUD invocations using Attributes in the client illustrates how you can separate client to server communication logic from contextually named methods for readability. On EITHER the server side OR the client side partial classes allow individual for deviations/customizations of the Entity depending client vs. server side distinction subtleties. Entity State can be bound to a UI Element to indicate entity state in a visual indicator/decorator can be done with little code and can be done in the IDE rather than in boring ugly, and tightly coupled source code.