With that ‘crazy’ Word XML Editor project of mine under some semblance of control, forces were directed toward other Enterprise Data Solutions based on the Microsoft .NET Framework. The idea over the last few days was to play the Microsoft game and wholly accept what they have to offer for data access. This leads directly to the
Before a few days ago, I blindly followed the whiz bang demos coming out of Redmond, which strongly imply that we should automatically generate our
DataSet definitions right on top of a Windows or Web form. This makes Access form coders and old-school Visual Basic developer feel right at home but, for those of us who have some passing respect for OOP, we will eventually want to clearly define our data access layer and reuse that layer for more than just one whiz bang project. Bang! This leads to the following bullets:
- Define a project that has one Component that will host data connections and adapters.
- This component will generate
DataSetdefinitions (classes) that will be referenced by other projects, their items calling out for data adapted to their framework. (This, by way, highlights the ‘referenced
DataSet,’ which I saw many times in the Visual Studio .NET, Generate Dataset dialog—under Choose a dataset: > Existing—but I did not know what that meant.)
I am sure these three shots out—not to be confused with shouts out—may seem obvious to seasoned .NET veterans who had the luxury of working with Beta bits on some virtual machine. I’m late to the party but I am earlier than the last shindig. I can clearly see in my mind the data story:
- First, there is the physical data store. The DBMS.
- Then there is the data component that adapts the physical data store into a volatile, in-memory representation of the persisted data store. This adaptation produces a strongly-typed dataset.
- The dataset is consumed by endpoints, including Web applications and smart clients.
There it is.