Hi
I have a requirement in my project which states that I must provide a UI that will be able to display data from any number of database tables. Those table structures will be changing through time and new tables will be added as well (outside the control of my application). The main hurdle is that the .Net code should not have to change and still be able to display any of those tables as they get added.
If we were using ADO .Net, I would create some metadata tables to store what table or query to display based upon user selection as well as keep track of column names, maybe column order, etc. I would extract the data itself into ADO datatables that I would use as the data source for my UI. Then I would use the metadata to properly format the UI display (suppose a datagrid as the UI).
What would be a good way to do the equivalent using CSLA business objects? Has anyone experience with this? Is it just not something that we should try to do with CSLA (other than for the metadata objects themselves)?
We are using CSLA 4.0 with VB .NEt on VS 2010.
There are various threads on this topic. It isn't directly supported by a CSLA base type, but it is possible.
The important thing is to understand how your particular UI technology's data binding expects to dynamically discover the type's shape. Some UI technologies use a custom type descriptor concept - based on interfaces defined in System.ComponentModel, and that's probably the most common solution overall.
A newer technique (that may not work with older UI technologies like Windows Forms) is the new 'dynamic' type concept in .NET 4, and maybe some of the slightly earlier DLR (dynamic language runtime) capabilities.
Ultimately though, the important this is to realize that data binding (for your UI technology) will rely on some specific technique to discover the shape of the dynamic object, and you need to honor and implement that technique.
If they are read-only displays I would just use the standard ado data set.
You could still have a csla read only class that maybe has a property for the dataset so you can still have control of how/when the data is fetched.
I generally agree. The only thing to be aware of is that there's no DataTable in Silverlight or on WP7, so it isn't a great long-term strategy if those technologies are of interest now or in the future.
Hello.
Etienne is my supervisor.
I will add that we are using WPF for the user interface.
I tried a simple mock up with a data table as a property in a read-only business object. This works fine in client-server mode but as soon as I try through the data portal I get an error - the message is slightly different depending on the endpoint. Named pipes gives be error 109.
Here is the code:
[View:http://forums.lhotka.net/cfs-file.ashx/__key/CommunityServer.Components.UserFiles/00.00.01.13.30/CslaRoObjectDataTable.txt]
Copyright (c) Marimer LLC