Category: MVVM

Apr 15 2011

Is it possible to generate a complete, working WPF/Silverlight/XAML application that emits best practices?

Hello,

Is there a way, given a database or some other source specification for an application, for an entire WPF or Silverlight / XAML application to be generated that emits best practices?

For example, assuming I have a well-normalized database (or some other kind of base specification for an app), is there a tool that can create a well-formed MVVM application. This would include...

  • XAML (Views) for all of the tables (list and edit) with no code-behind
  • ViewModels that emits properties extracted from the db schema along with commands or behaviors for all of your standard CRUD operations
  • Models built with the repository pattern (or some other db abstraction) with interfaces that emit the table design and relationships and a default implementation of your choice (sql, sql ce...whatever).

An ideal tool like this would only do a "first pass" of the application after which the developer would make all necessary changes and modifications.

I don't think there is any such tool but it seems like a tool like this should be possible.

Another related question, in the absence of such a tool (or even if there is one), what tool(s) are best used to get me from a database design (or some other kind of base specification for an app) to working app.

What STEP-BY-STEP process do you take to get from design to basic working application in a couple of hours?

I am just trying to figure all of these practices and patterns and I am getting a pretty good grasp of the pieces but not sure what workflow to use to make it all work together quickly but still allows unit testing of separate concerns.

Thanks in advance.

Seth

Apr 15 2011

Is it possible to generate a complete, working WPF/Silverlight/XAML application that emits best practices?

Is there a way, given a database or some other source specification for an application, for an entire WPF or Silverlight / XAML application to be generated that emits best practices?

For example, assuming I have a well-normalized database (or some other kind of base specification for an app), is there a tool that can create a well-formed MVVM application. This would include...

  • XAML (Views) for all of the tables (list and edit) with no code-behind
  • ViewModels that emits properties extracted from the db schema along with commands or behaviors for all of your standard CRUD operations
  • Models built with the repository pattern (or some other db abstraction) with interfaces that emit the table design and relationships and a default implementation of your choice (sql, sql ce...whatever).

An ideal tool like this would only do a "first pass" of the application after which the developer would make all necessary changes and modifications.

I don't think there is any such tool but it seems like a tool like this should be possible.

Another related question, in the absence of such a tool (or even if there is one), what tool(s) are best used to get me from a database design (or some other kind of base specification for an app) to working app.

What STEP-BY-STEP process do you take to get from design to basic working application in a couple of hours?

I am just trying to figure all of these practices and patterns and I am getting a pretty good grasp of the pieces but not sure what workflow to use to make it all work together quickly but still allows unit testing of separate concerns.

Thanks in advance.

Seth

Mar 31 2011

Thoughts on WPF / MVVM Tutorial

Yesterday I spent a couple of hours going through Karl Shifflet’s In the Box Training for WPF / MVVM.  There is a lot of great things I could say about In the Box format for developer training but for today it will have to suffice to say that it is awesome—mostly because it directly integrates with Visual Studio.  

And Karl REALLY knocked himself out with the content.  Except for a few reasonable WPF pre-reqs, this is “ground-zero” training that does not presume on anything.  

I just wanted to documents some takeaways and thoughts on what I learned so that next time I do  the content (I will very likely go through this training multiple times) I won’t be starting over each time.

I thought I would present this in the form of a brass tacks bulleted/ordered list of the steps I would take to complete an MVVM application.

WARNING – these instruction are ultimately WAY to simplistic and does not represent a REAL way to architect and design an application but should work for me based on what I know.

  • First wireframe your UI / Screens and Interactions using Balsamiq Mockups.
  • Create a WPF project and then create a MainPage view in XAML for each major screen and separate xaml views for each logical component of your UI. 
    • The Views and main form will have “empty” code-behind files except for the boilerplate InitializeComponent().  This is how you know you are doing MVVM instead of a traditional windows app.
    • The bootstrapping of the App will be done later, using an IOC container, in the app startup event after all of the ViewModels are completed .
    • For more on this see the UI Design and Bootstrapping sections of the tutorial.
  • Create your Domain objects.  The classes here are just very simple POCOs (plain old clr objects) with no methods.  I think this is because all of the business logic is in the ViewModel itself.  
    • The POCOs had no methods, only property setters and getters.
    • With the exception of light-weight items used to fill lists, all of the objects inherit from ObservableObject.  ObservableObject is a utility class provided in the tutorial that implements INotifyPropertyChanged which is a core WPF interface for using the WPF property system.
    • For light-weight “listable” items that map to real objects but only have the properties needed to fill the list, you do not need to inherit from Observsable object.
    • If any property members are collections make the collection a generic type of ObservableCollection (i.e. ObservableCollection<Expense> _expenses 😉
    • All of the property setters should call the RaisePropertyChanged method passign the property name as a string argument (i.e. RaisePropertyChanged("Notes") 😉
    • All of the Observable POCO clasess are marked as Serializable.  
    • All of the Observable POCOs had a default constructor with no overloaded cosntructor.
    • The light-weight POCO did have a overloaded constructor that hydrates the object.
  • For data access, create a I<OBECT>Repository interface and a matching class for implementing the interface for each domain object.
    • The interface will have all of your basic DAL stuff.  For example…
    • Event GetById(Guid id);
      Int32 Remove(Event @event);
      Int32 Save(Event @event);
      Int32 GetCount();
      Event Create();

    • The example interface also had a method for getting a collection of light-weight IEnumberable (i.e.  IEnumerable<EventSearchResult> GetSearchResults();)
    • The repository implementation will have a private field that keeps a list of objects of the type (i.e. readonly List<Event> _events;)
    • The constructor of the implementation hydrates the POCOs and adds them to the list.  This is great for swapping out DALs at any time and unit testing.
    • Of course, you add implementation for all of the interface defs.  (I wonder what an implementation that actually hits the database would look like?)
  • Create a ViewModel for each major Screen. 
    • A ViewModel is the DataTemplate for the screen and all of the child views/components of that screen. 
    • The startup event of the application wires the main screens (views) to the ViewModel as the DataTemplate.
    • The ViewModels also inherit from ObservableObject.
    • As needed, the ViewModel contains instances of all relevant Domain POCOs and light-weight POCOs and collectionSleeping half-moon of POCOs as needed..  
    • It may implement properties that track the current or active or selected POCO instance.
    • The ViewModel will also have private, read-only fields that hold references to the repository objects that it needs (readonly IEventRepository _repository;)
    • As with the Domain POCOs, the property setters call the RaisePropertyChanged methods. 
    • Some of the property setters can set the Acive / Selected object (i.e. RecordSelected(value);)
    • View and view model interactions are handled through the create of ICommand objects.  The tutorial provides and implementation of this in the RelayCommand class which is what the ICommand method construct and return.   He goes into some length to explain why he implemented this ICommand instead of using the built-in DelegateCommand.
    • View / ViewModel interactions can also be done by defining “behaviours” in the view but this is not explained or demonstrated in the turtorial.
    • Different strategies for implementing and using ICommands are demonstrated.
    • The tutorial also gives helpful information on how to invoke dialog boxes from the ViewModels. 
    • The ViewModel also implements Can<COMMAND>Execute methods that have to be very fast along with void <COMMAND>Execute methods that interact with the collections and repositories to do CRUD operations on the data.
    • A single ViewModel can serve as the DataTemplate for all of the view and child views/components. 

IMPORTANT – PROBABLY THE MOST important thing to understand and master in the tutorial is the page call View-View Model Interactions.  Maybe a future post will explore that in greater details.  But below are the relevant topics.

EventEditView Bindings

The below XAML snippet from EventEditView.xaml illustrates one technique for binding UI controls to model objects exposed from a view model.

The DataContext for this view is the view model. ActiveEvent is a property on the view model. Each of the controls “dot in” to the property on the model object they want to bind to.

<TextBox Text="{Binding Path=ActiveEvent.Title, Mode=TwoWay}" />

<TextBox Text="{Binding Path=ActiveEvent.Location, Mode=TwoWay}"/>

<DatePicker Text="{Binding Path=ActiveEvent.EventDate, Mode=TwoWay}"/>

<TextBox Text="{Binding Path=ActiveEvent.Notes, Mode=TwoWay}"/>

<DataGrid ItemsSource="{Binding Path=ActiveEvent.Expenses}" .../>

It is also possible to assign the ActiveEvent instance to a parent container’s DataContext like a Grid control and then the child controls would not have to “dot in” since their DataContext root would be the ActiveEvent instance instead of the view model instance.

Commands

The MainWindowViewModel exposes the following five ICommand properties; the EventEditView data binds to those properties.

public ICommand DeleteCommand {

get { return new RelayCommand(DeleteExecute, CanDeleteExecute); }

}

public ICommand SaveCommand {

get { return new RelayCommand(SaveExecute, CanSaveExecute); }

}

public ICommand CancelCommand {

get { return new RelayCommand(CancelExecute, CanCancelExecute); }

}

public ICommand ThrowCommand {

get { return new RelayCommand(ThrowExecute, CanThrowExecute); }

}

public ICommand NewCommand {

get { return new RelayCommand(NewExecute); }

}

<StackPanel Orientation="Horizontal" Grid.Row="5" Grid.ColumnSpan="2">

<Button Content="New" Command="{Binding Path=NewCommand}" />

<Button Content="Save" Command="{Binding Path=SaveCommand}" />

<Button Content="Cancel" Command="{Binding Path=CancelCommand}" />

<Button Content="Delete" Command="{Binding Path=DeleteCommand}" />

<Button Content="Throw" Command="{Binding Path=ThrowCommand}" />

</StackPanel>