Wednesday, April 16, 2008
Data Load Controllers
We have recently introduced a fully-automatic way of creating external data loading mechanisms. This is achieved by means of so-called "data load controllers". So what is the basic idea behind these? Well, I am glad you asked! :-)
Milos provides great ways to load data in all kinds of data edit forms, from Windows to the Web, in all kinds of variation. For instance, one can simply use the SetEntityType<>() method to automatically load an entity of a certain type in a window or a web form. It is also possible to override LoadContents() and LoadSecondary() data methods to load additional data, or load it in slightly different ways.
This makes for easy ways of loading data. However, in some scenarios, we want to go even further. (We will always continue to support this approach as it provides the basis for all operations, but we want to provide more options). There are a few scenarios we want to simplify. Here are those considerations:
- This approach generally relies on inheritance. That is OK in many scenarios, but in some scenarios (such as ASP.NET web forms or WPF/Silverlight XAML), there are scenarios where one just wants to use an object instance for data loading. For instance, one might want to put a data panel into a web form without explicitly subclassing it. Those scenarios are currently supported by means of an event model. That is not a bad approach, but it is slightly different from the inheritance model, and the written code is not IL-compatible, since method signatures are differently, and so forth.
- Different interfaces may have a need to load the same data. For instance, 10 different forms of a windows application may need to load certain lookup tables. Or, an ASP.NET web form may need to load the same exact data as the WinForms or WPF equivalent. Neither the inheritance, nor the event model allows for simple code reuse in these scenarios.
- It is very hard to unit test data loading for UIs if the code is embedded in, or attached to the user interface classes.
We now provide an additional abstract option: All the data loading (and data handling) code can be put in an abstract class. Here is an example of such a class:
public class NameEditLoader : DataLoadController
{
public override void Configure()
{
this.SetEntityType<NameBusinessEntity>();
}
public override object LoadSecondaryData()
{
NameBusinessObject names = NameBusinessObject.NewInstance();
DataSet dsNames = names.GetList();
names.Dispose();
return dsNames;
}
}
If you are familiar with current Milos loading code, then you will recognize all of this, because the code is identical to code that would go into a Windows Forms class as well as other types of UI classes. The main difference is that this code now sits in an external class. This class can now be used in an interface class. For instance, it could be used in a Windows Form or a WPF window like so:
public MyWindow() // Constructor
{
InitializeComponent();
this.DataLoadControllers.Add(new NameEditLoader());
}
The same exact object can also be used on a web form:
protected void Page_Load(object sender, EventArgs e)
{
this.dataEditPanel1.DataLoadControllers.Add(new NameEditLoader());
}
The same object could also be used in XAML, or in a mobile app, and so forth. Also, the object can now be used stand-alone in unit test scenarios, which is extremely important in test driven development (TDD) and other scenarios where unit tests are needed. (And most applications need unit tests these days).
So we think this is a cool change. It is completely optional and everything that was there before is still available. But going forward, this is clearly the recommended approach.
Posted @ 4:08 AM by Egger, Markus (markus@code-magazine.com)
Post a Comment:
Comment Title (required):
Your Name (optional):
Your Email (optional):
Your Web Site (optional):
Your Comment (required):