I've been slowly replacing all my WinForms UI with XAML UI and in the process implemented the ViewModel approach to data binding. One of the great disconnects to this whole process seems to be the way "Design time data" can be used. Previously I looked at DesignTime_Create dataportal methods to help achieve this, but I'm not sure how that would be implemented in the ViewModel constructor in the UI.
The pattern for the ViewModel include the following (VB code example) approach.
Public Class MyVMBase(Of T) Inherits Csla.Wpf.ViewModelBase(Of T)
Sub New() MyBase.New() If System.ComponentModel.DesignerProperties.GetIsInDesignMode(Me) Then ' Is this where DesignTime_Create should go or
' does the ViewModelBase automatically pick up that dataportal code. Return End If BeginRefresh("GetAllAsyncWithAllEntry") End Sub
Now when we get into the VS2010 IDE and wiring up the new ViewModel UI, it would be really nice to have a single sample record to make the design process more realistic. Hence my review of DesignTime_Create, the obvious design data population technique. However the CSLA source code doesn't seem to have ViewModel code tied to any of the DesignTime_Create code, which was unexpected. Is this an oversight?
Ok, so I then continue into Blend 4 to see how the "data" feature would tie together and again, I'm a little confused about how my lovely CSLA business object and the data tools in that software should interact. The CSLA 4 videos and online books haven't covered these topics in any detail, so I'm assuming that its a "IDE limitation" or I'm barking up the wrong tree. Has anyone gone down this path?
Having the business layer generate design time data is a mismatch of concepts. I did dabble with that idea early on, but it causes way more problems than it is worth - especially when it is really not the business layer's job.
It is the presentation layer's job to help designers build a good presentation. There are a couple options you can pursue.
One is to create dummy sample data types that are directly used by the XAML at design time. This is what Microsoft tends to do with their project templates for things like WP7 and Metro. I don't think they did so much of that for WPF/SL, but the same techniques apply.
Another is to create dummy sample data and return it from the viewmodel objects. So your viewmodel (probably in the constructor) recognizes that it is running in design time and returns some fake dummy objects instead of real objects. This can be a little harder, because your viewmodel is probably strongly typed.
I'm going to assume this statements means that DesignTime_Create should really be marked [Obsolete("Don't use this method on pain of death")] in the CSLA codebase. I tend to agree that XAML design data for UI layout probably should stay in the UI side of things and I think I can fudge Blend 4 + into do some strongly typed random data based on some testing I've done.
Mock or Test Data.
I know mock/test data can be another form of useful UI testing. From what I can recall, recommendations for are
I'm thinking in terms of a external software development resource that needs to have some data to work with, but not "real/sensitive" data. What's the guide on this? I'm trying to keep away from IOC containers as I'm a noob in that area and I'm not sure CSLA and existing IOC have a good relationship.
Design time create functionality was removed in 3.8 or 4 (I don't remember which). If you are using a version that still has the implementation, it was a valid technique at that time, but it was removed later.
The mock DAL technique is very valid. I discuss it in detail in the Using CSLA 4: Data Access book, including sample apps that include a mock provider. You don't need IoC to make this work, you can use a simple provider model that I show how to build. Or you can use IoC - that's really up to you.
Copyright (c) Marimer LLC