I made a blog post a while ago in a thread entitled "Microsoft ruined data binding in ASP.NET 2.0 when they dropped component support from the design surface" and thought it worthy of a follow up.
ICustomTypeDescriptor
In order to allow strongly typed entities to tack on dynamic properties (extra columns brought back via a dynamic query) for data binding in ASP.NET data grid scenarios you must implement the ICustomTypeDescriptor interface. Since our latest release (v1119) supports joins it is now common to bring back extra columns for display purposes in EntitySpaces. Well, we implemented the ICustomTypeDescriptor interface on our esEntity class and it worked perfectly in ASP.NET, however, testing then showed it broke data binding in certain Windows.Forms scenarios. Why? There is a BUG in the Microsoft.NET Framework. It's not like bugs are not found in EntitySpaces of course, this is merely an explanation of how we have arrived to this point.
We have a few ways to work around the issue. One is to use our Collection.LowLevelBind() method and the other is adding properties to your entity (not very attractive). Our esDataSource control allows you to bring back extra columns and it binds just fine, there is a "LowLevelBind" method on the esDataSource for just this scenario. This only effects ASP.NET as Windows.Forms uses ITypedList which works like a champ (in hierarchical mode also).
HierarchicalDataSourceControl
The new HierarchicalDataSourceControl binding set of interfaces proved utterly incapable of displaying a hierarchical object model. We had it "kind of working" when we realized that this new binding model only supported a single parent/child relationship. This means it cannot display the EntitySpaces hierarchical object model. So, we withdrew the implementation of this feature. Scott Piegdon has a code sample on CodeProject, you can see his response to my "Ya, Butt" comment which validated my suspicions (nice article by the way).
Summary
Again, the new Microsoft ASP.NET data binding has proven to be flawed. It is next to impossible to support both ASP.NET and Windows.Forms binding with the same codebase due to a serious bug in the .NET Framework. Also, the HierarchicalDataSourceControl implementation suffers from a lack of foresight by its designers.
And finally (whining here) this all worked in the Microsoft .NET 1.x framework, see Part One as to how we got to where we are. The same ITypedList implementation worked for both ASP.NET and Windows.Forms. However, it was swapped out for some crazy DataSource model that is clearly geared for heavily reflected architectures. Well, EntitySpaces didn't take the bait. We are still 100% reflection free. We still run in "Medium Trust" and yes, we support the DataSource control but not the HierarchicalDataSourceControl. We have a plan to work around this issue entirely in a future release.
From mobile devices to large scale enterprise solutions in need of serious transaction support, EntitySpaces can meet your needs. Whether you’re writing an ASP.NET application with medium trust requirements, or a Windows.Forms application, the EntitySpaces architecture is there for you. EntitySpaces is provider independent, which means that you can run the same binary code against any of the supported databases. EntitySpaces is available in both C# and VB.NET. EntitySpaces uses no reflection, no XML files, and sports a tiny foot print of less than 200k. Pound for pound, EntitySpaces is one tough, dependable .NET architecture.
The EntitySpaces Team
--
EntitySpaces LLC
Persistence Layer and Business Objects for Microsoft .NET
http://www.entityspaces.net