Sundew. Application Framework

Transcription

1 Sundew Application Framework

2 Contents Hukano Sundew... 3 Introduction... 3 Idea and motivation... 3 The Sundew Application Model... 4 Architecture... 4 Model-View-ViewModel according to Hukano... 5 ViewModels... 5 ViewModel hierarchy... 5 Lists... 7 Mediator... 8 PropertyMap... 9 Input Validation Interaction engine/command model Command tree handling Example Web: 2

3 Hukano Sundew Introduction Sundew requires some familiarity with XAML and the Model-View-ViewModel (MVVM) design pattern. Readers of this document should have a basic understanding of DataBinding and working with XAML. More information about WPF: More information about Silverlight: More information about Windows Phone 7: More information about MVVM design pattern: Sundew aims to support the latest Microsoft Development platforms: Windows Presentation Foundation 4 (WPF), Silverlight 4 (SVL) and Windows Phone 7 (WP7). All functionality builds on top of.net framework, which ensures the best compatibility now and for future versions. Due to differences in the Microsoft platforms Sundew feature also differ in some cases. At the moment it is possible to single source large amounts of code and Hukano focuses on making the API s even more compatible for future versions of.net. Idea and motivation The idea and motivation behind the Sundew framework, compared to other MVVM frameworks, is to create a framework that promotes implementing business logic in a testable fashion. Main focuses are: Supporting extremely thin GUI layer, by moving implementation to business layer Completely unit testable business layer Possibility to run coded GUI tests without GUI dependencies Support Expression Blend as a design tool Mapping requirements (e.g. user stories) closer to actual implementation Highly extensible/overridable Streamline developing.net applications across Microsoft platforms with a unified API Strongly typed Web: 3

4 The Sundew Application Model Architecture Sundew framework is a base class library assisting developers in implementing the business layer when working with the Model-View-ViewModel design pattern. The following illustration shows the placement of the Sundew framework in a multi-tier architecture. Presentation Layer Separation ValidationRules & IValueConverters Viewing with.net DataBinding Commanding Microsoft.NET Business Logic Input Validation on top of WPF Validation model ViewModeling Command engine on top of Command model Hukano Sundew Layer Separation WeakListening Data Modeling Object Relation Mapping Other framework The illustration shows that Sundew interfaces in three areas with.net, for validation, databinding and commanding. ViewModeling assists in presenting data to the user. Input Validation handles validating input from a user e.g. when typing text in a TextBox. The interaction engine handles commands executed by the user. All subjects will be described further. Web: 4

5 Model-View-ViewModel according to Hukano ViewModels Throughout this document the terms View, ViewModel and Model will be used frequently, the illustration below shows their relationship. View ViewModel : ViewModel<TModel> Model : NotifyingObject In MVVM the view-model acts as a wrapper for the model in order to prepare the model for the view. The view holds a reference to the view-model (FrameworkElement.DataContext property) and the view-model holds a reference to the model (ViewModel<T>.Model property), but never in the other direction. The.NET Binding engine listens to property change notifications on the view-model through the INotifyPropertyChanged interface. Reference on MSDN: In the same fashion, the view-model listens to changes in the model. This is implemented with weak referencing to ensure that there is never a strong reference from the model to the view-model through the PropertyChangedEventHandler delegate. Sundew provides a ViewModel base class which comes in both standalone and generic versions. Also a NotifyingObject class is provided and it can be used as the base class for models. Models are required to implement to INotifyingObject interface and notify listeners when properties change. ViewModel hierarchy The purpose of the view-model hierarchy is to build a hierarchy of view-models similar to the hierarchy of models. It also makes parent/child relationships between view-models and thus providing the possibility to run input validation down the view-model hierarchy. The hierarchy is maintained by a simple API, quite similar to the DependencyProperty system of.net. It requires creating a ViewModelProperty using the static Register method found on the ViewModelProperty class. The Get- and SetViewModelChild method found on the ViewModel class gets and sets the child view-model by taking the ViewModelProperty as a parameter. Web: 5

6 The class diagram below shows the ViewModel base classes and their public/protected interface. Web: 6

7 Lists Working with lists is made easy with the ObservableCollection class in.net. An ObservableCollection will notify changes in the list through the INotifyCollectionChanged interface similar to the way the INotifyPropertyChanged interface work. This means that Views will be automatically updated if for example a new item is added to the list. In Sundew a list of models is also considered a model itself and thus a list of view-models and a list of views exist. ListView ListViewItem ListViewItem ListViewItem ListViewModel <TModel, TItemViewModel> ItemViewModel ItemViewModel : ItemViewModel :: ItemViewModel ItemViewModel <TContainerViewModel, <TContainerViewModel, TModel> <TModel, TParentViewModel> TModel> NotifyingCollec tion<tmodel> Model Model : Model : : NotifyingObject NotifyingObject NotifyingObject The NotifyingCollection is a Sundew class derived from ObservableCollection and extends implementation with the INotifyCollectionChanging interface. The base class ListViewModel ensures synchronizing changes in the NotifyingCollection, which means there will always be a ViewModel for any model in the list. Sundew also provides base classes for trees and nodes. The use is similar to that of ListViewModel. See NodeViewModel in the API reference documentation. Web: 7

8 Mediator The responsibility of the Mediator is to provide inter- view-model communication. Consider the sample illustration below. Person FirstName get; set; LastName get; set; PersonViewModel1 FirstName get; LastName get; IsSelected get; Mediator used to notify IsSelected changed PersonViewModel2 FirstName get; set; LastName get; set; IsSelected get; set; As the illustration shows: The Person model has two properties FirstName and LastName. PersonViewModel1 is a read only view-model since it only has get properties. PersonViewModel2 can both read and write to the model. Both ViewModel implements a third property IsSelected. Since IsSelected has nothing to do with the model of being a person, the property does not exist in the Person class. The problem is that the two view-models have similar data, but since they have no knowledge of each other, PersonViewModel1 is unable to react to changes in PersonViewModel2s IsSelected property. Using the Mediator class in the Sundew.Mvvm.Messaging namespace it is possible to notify relevant ViewModel siblings about changes. The Sundew Mediator is implemented using Sundew WeakEvent, which ensures that no memory leak occurs. Web: 8

9 PropertyMap The PropertyMap eases handling property change notifications. The generic PropertyMap class takes two arguments PropertyMap<TSender, TListener> and allows the developer to map property notifications on the sender to notify a property on the listener. Also registering handlers to the mapped properties is possible for implementing custom code. Both the interfaces INotifyPropertyChanged and the INotifyPropertyChanging are supported, when implemented by the listener and the sender. All view-models derived from ViewModel<TModel> include a PropertyMap, which allows mapping property changes to handlers in the view-model. This provides an easy and clean way of handling property change notifications. Web: 9

10 Input Validation NB! Input validation is only available in WPF due to limitations of Silverlight and Windows Phone 7. A unified validation engine will be provided when allowed by the.net framework. The Validation model is a part of the DataBinding engine in WPF. Please refer to the DataBinding overview on MSDN: The validation process involves 4+1 steps: 4 validation steps and one conversion step. The steps are executed in the following order: 1. RawProposedValue validation 2. Value Conversion 3. ConvertedProposedValue validation 4. UpdatedValue validation 5. CommittedValue validation In.NET it is required to derive from the abstract class ValidationRule to implement validation. In order to implement a converter the interface IValueConverter must be implemented. The validation model does have limitations, as there is no framework support for specifying whether a field is required or optional and fields are either valid or invalid. With Sundew, fields can also be incomplete. Sundew solves all of these problems by providing new base classes for ValidationRule and IValueConverter: The FeedbackConverter and the FeedbackValidationRule add support for incomplete validation status. Consider the GUI below. In this case the Name field is only accepted for input when the name exceeds three characters. The blue icon indicates that the field is required. Web: 10

11 The sample is implemented using a FeedbackTemplate set on the Attached DependencyProperty on the Feedback class in the Sundew.ValidationModel namespace rather than using the ErrorTemplate property on the WPF Validation class. It is also necessary to use the Sundew.ValidationModel.AdornedViewPlaceholder when making the feedback template instead of the WPF AdornedElementPlaceholder. BindingExpression and BindingGroups may be exposed to the view-model with the Sundew.Xaml.Bindings.FillViewModel property and therefore enabling validation from the view-model. The BindingExpression and BindingGroups are exposed by the ViewModel.Validation property. For an easier way to create converters in XAML use the Sundew.Xaml.TypeFactory markup extension. Web: 11

12 Interaction engine/command model The interaction engine in Sundew is built on top of the.net Command model in order to provide the best possible support for decoupling from the GUI. The engine was designed to solve a number of challenges when developing.net applications. Decoupled from GUI Command tree handling Unit testing support Basic error handling Command tree handling The tree is built by defining CommandDefinitions and thus specifying how commands are related. Multiple command trees are supported by creating multiple CommandTree classes. The root in each CommandTree is called Default. Consider the tree below: <Default> CreateProfile Transition SaveProfile Command SaveProfile may be executed either when CreateProfile or EditProfile is the current command EditProfile Transition DeleteProfile Command SaveProfile Command As the illustration suggests, there are two types of CommandDefinitions: Command and TransitionCommand. Commands are registered with CommandTree.RegisterCommand. TransitionCommands are used to enter to a new state and doing so will only allow commands, which are children of the TransitionCommand, to run. TransitionCommands are registered with CommandTree.RegisterBegin. To return from a TransitionCommand, a CommandDefinition that is registered with CommandTree.RegisterEnd, must be executed. If a user executes the CreateProfile TransitionCommand followed by the SaveProfile Command, the engine will call methods in the following order: CreateProfile.Execute() o SaveProfile.Execute() CreateProfile.EndExecute() Web: 12

13 Example To define a command four steps are mandatory: 1. Create a CommandTree public static readonly CommandTree ProfileCommandTree = new CommandTree ("Main"); 2. Implement the command by deriving from the abstract Command<TContext> class or TransitionCommand<TContext> class. public class CreateProfile : TransitionCommand<UnassignedProfileVM> public override void CanExecute(UnassignedProfileVM context, CanExecuteEventArgs e) e.canexecute = true; public override void Execute(UnassignedProfileVM context, ExecuteEventArgs e)... public override void EndExecute(UnassignedProfileVM context)... public class SaveProfile : Command<ProfileSettingsVM> public override void CanExecute(ProfileSettingsVM context, CanExecuteEventArgs e) e.canexecute =!context.validation.haserrorrecursive; public override void Execute(ProfileSettingsVM context, ExecuteEventArgs e) context.model.getunitofwork().save(); 3. Define a CommandDefinition and map it to the Command or TransitionCommand, CommandDefinitions may be created with the Register methods on the CommandTree class. public static readonly CommandDefinition CreateProfileAction = ProfileCommandTree.RegisterBegin<CreateProfile>("CreateProfile"); public static readonly CommandDefinition SaveProfileAction = ProfileCommandTree.RegisterEnd<SaveProfile>("SaveProfile", new CommandDefinitions(CreateProfileAction)); public CommandDefinition SaveProfile get return SaveProfileAction; public CommandDefinition CreateProfile get return CreateProfileAction; 4. Assign the CommandDefinition to a view element with the Attached DependencyProperty CommandDefinition found in the Sundew.Xaml.Interaction class. <Button xaml:interaction.commanddefinition="binding CreateProfile" Content="Create Profile"/> <Button xaml:interaction.commanddefinition="binding SaveProfile" Content="Save Profile"/> It s possible to bind a command directly to an event of a view through the EventCommand class. The EventCommand supports unit testing by providing an API for extracting data from EventArgs. <Canvas> <xaml:interaction.triggers> <xaml:commandtrigger EventName="Drag" CommandDefinition="Binding MoveItem"/> </xaml:interaction.triggers> </Canvas> Web: 13