Design-Time Features > Live Views |
Live views is a powerful feature, so let’s take a little more time to see what live views can do. Live views are designed to make data binding more powerful, so powerful, in fact, that you can develop virtually entire applications with just LINQ (in its LiveLinq form) and data binding.
Live views, called LiveLinq, a part of DataSource for Entity Framework, is a client-side, in-memory feature applicable not only to Entity Framework and RIA Services data, but to any observable collections in memory, including XML (LINQ to XML object model) and ADO.NET DataSets.
So, for example, you can use live views over Entity Framework data and some other data (for example, XML retrieved from some web service) to integrate that data and to provide easy full-featured data binding to the integrated data. This is a powerful tool for building applications that get data from various sources. For now we’re going to concentrate on how we can use it with the Entity Framework, but if you’d like to explore LiveLinq in greater depth, see the ComponentOne LiveLinq documentation.
In fact, we already saw an example of such customization in Customizing View. But there we only changed the properties (fields) of the view and only applied one LINQ operator, Select. Let’s apply some more LINQ operators to transform the view. What we do here will be similar to what we did in Customizing View, but instead of using C1DataSource, we’ll be doing everything in code.
To use live views, follow these steps:
To write code in Visual Basic
Visual Basic |
Copy Code
|
---|---|
Private _scope As EntityClientScope = Program.ClientCache.CreateScope() |
To write code in C#
C# |
Copy Code
|
---|---|
private EntityClientScope _scope = Program.ClientCache.CreateScope(); |
To write code in Visual Basic
Visual Basic |
Copy Code
|
---|---|
_viewProducts = (From p In _scope.GetItems(Of Product)() Where Not p.Discontinued And p.UnitPrice >= 30 Order By p.UnitPrice Select New With { p.ProductID, p.ProductName, p.CategoryID, p.Category.CategoryName, p.SupplierID, .Supplier = p.Supplier.CompanyName, p.UnitPrice, p.QuantityPerUnit, p.UnitsInStock, p.UnitsOnOrder }).AsDynamic() dataGridView1.DataSource = _viewProducts |
To write code in C#
C# |
Copy Code
|
---|---|
|
In this example, we applied several LiveLinq operators: Where, OrderBy, and Select. We defined our view as containing products that aren’t discontinued and have a unit price of at least 30, and we sorted our view by unit price.
We chose to store the view in a private field _viewProducts here:
To write code in Visual Basic
Visual Basic |
Copy Code
|
---|---|
Private _viewProducts As View(Of Object) |
To write code in C#
C# |
Copy Code
|
---|---|
private View<dynamic> _viewProducts; |
That is only because we will need it later. If we did not, we could use a local variable for the view.
Syntactically, the query that we wrote for _viewProducts is just standard LINQ. It could be done without C1DataSource, with standard LINQ to Objects, and the code would be the same, only instead of _scope.GetItems<Product>(), you would use something like ObjectContext.Products. In fact, we will try to do just that in a moment, once we run the project, to compare what we get from standard LINQ with what we get from LiveLinq.
To appreciate this full data binding support, compare it with what you would get if you did not use C1DataSource, but if you used standard LINQ to Objects instead. It’s easy to compare; just replace _scope.GetItems<Product>() in the code with Program.ObjectContext.Products. Note that you will also need to remove the type C1.LiveLinq.LiveViews.View and use the 'var' keyword instead for it to compile, because it will no longer be a live view. The difference is obvious: with standard LINQ, the data in the grid is read-only, and the grid does not support sorting.
But live views offer even more great features. Standard LINQ to Objects produces snapshots of the data that cannot reflect changes in the source data, except some simple property changes, and even then under the strict proviso that you don’t utilize a custom Select in your LINQ statement. Live Views, on the other hand, provide dynamic ‘live’ views that automatically reflect changes in their source data. As such, they simplify application development because you can, in most cases, rely on data binding to automate ‘live’ changes in views without the need to synchronize the changes in different parts of the application with code.
To see that the views are indeed ‘live’, open two forms side-by-side. Run your application and open up the Custom Columns form, which we built in Customizing View, and the Client Side Querying form, which we just built here. Make some changes to a product in the CustomColumns form and observe how they are reflected in the other form. If, for example, you were to increase the UnitCost of a product to above 30, then it would automatically appear in the second form.
To see another example of how live views automatically synchronize themselves with changes in underlying data, follow these steps:
To write code in Visual Basic
Visual Basic |
Copy Code
|
---|---|
Private _seafoodProductsView As ClientView(Of Product) |
To write code in C#
C# |
Copy Code
|
---|---|
private ClientView<Product> _seafoodProductsView; |
To write code in Visual Basic
Visual Basic |
Copy Code
|
---|---|
_seafoodProductsView = _scope.GetItems(Of Product)().AsFiltered(Function(p) p.CategoryID.Value = 8) |
To write code in C#
C# |
Copy Code
|
---|---|
_seafoodProductsView = _scope.GetItems<Product>().AsFiltered(p => p.CategoryID == 8); |
To write code in Visual Basic
Visual Basic |
Copy Code
|
---|---|
Private Sub raiseButton_Click(sender As System.Object, e As System.EventArgs) |
To write code in C#
C# |
Copy Code
|
---|---|
|
labelCount.DataBindings.Add(new Binding("Text",
_viewProducts.LiveCount(), "Value"));