I've been looking at an alpha for about a month now, and have found
one aspect of Whidbey that I'm excited about.

Some words from a project I'm working on:

While I still have quite a bit of investigation to do, I have a
feeling that ObjectSpaces will become to .Net 2.0 what Datasets are
to .Net today. In addition, I also believe that becoming familiar
with ObjectSpaces is going to require some mind bending.

The reason for the mind bending is this, ObjectSpaces do not appear
to follow current "traditional" modes of application architecture.
What I mean by this is that good application developers these days
(in the .Net world) get wrapped up in tiers, and rightfully so. At a
minimum, a decent application architecture will contain 3 tiers or
layers. A UI layer, a business object layer, and a data layer. More
robust architectures may contain even more layers to, in theory, make
it easier to switch out "major" application areas such as a database
or a UI.

My current work environment is an example of the latter. We use
business manager objects that call data accessors to populate
business entity objects. The business manager objects are accessed
from a façade layer, and the façade layer is accessed from what we
call a proxy layer. The layers, if you will, resemble:

Add concurrency handling, exception handling and transaction
management, and it could take anywhere from several hundreds of lines
of code to several thousand to get a bit of data from the database to
the user interface (UI). We have a tool that allows us to generate
canned create, read, update and delete (CRUD) functionality and a
mechanism that allows for some degree of specialization. But, what we
loose with this ability to rapidly generate code is the flexibility
to create complex objects.

If you're a patterns geek, the above process helps to
create "gateway" types of objects that create a one-to-one
relationship between a table and an object. And again, this approach
works well most of the time. But when it doesn't, well, for the most
part it just doesn't.

So, ready for the mind bending? How does the ability to not only
create one-to-one relationships, but also the ability to create one-
to-many relationships (both one object to many tables, and one table
to many objects), and the ability to create many-to-many
relationships sound? How about the .Net framework managing this
functionality natively? How about being able to sub query an object
(or object graph) without requiring another trip to the database?
Have I mentioned yet that the object schemas and relationships are
written in XML? This is indeed exciting technology! Even the
venerable dataset are not quite so easy to use. A distinct "update"
command is required for queries that span multiple tables, requiring
a potentially complex stored procedure. Using ObjectSpaces though,
all that is required is to set up maps, and the framework manages the
rest.

In general, there are three mapping files required. A Relational
Schema Diagram (RSD), an Object Schema Diagram (OSD), and a Mapping
file. These mapping files are XML representations of the source
(typically a database), targets (the objects themselves), and a
mapping schema that maps object members to data columns.

(At this point, the best I can do is provide a glimpse of the XML
files, and explain what I do know).

The RSD:

<rsd:Database Name="Northwind" Owner="sa"
xmlns:rsd="http://schemas.microsoft.com/data/2002/09/28/rsd">
<r:Schema Name="dbo"
xmlns:r="http://schemas.microsoft.com/data/2002/09/28/rsd">
<rsd:Tables>
<rsd:Table Name="Customers">
<rsd:Columns>
<rsd:Column Name="CustomerID" SqlType="nchar"
Precision="5" />
<rsd:Column Name="CompanyName" SqlType="nvarchar"
Precision="40" />
<rsd:Column AllowDbNull="true" Name="ContactName"
SqlType="nvarchar" Precision="30" />
<rsd:Column AllowDbNull="true" Name="Phone"
SqlType="nvarchar" Precision="24" />
</rsd:Columns>
<rsd:Constraints>
<rsd:PrimaryKey Name="PK_Customers">
<rsd:ColumnRef Name="CustomerID" />
</rsd:PrimaryKey>
</rsd:Constraints>
</rsd:Table>
</rsd:Tables>
</r:Schema>
</rsd:Database>

One table is defined in this RSD. The table name is Customers, and
four columns are defined. A Primary key is defined as well.

The OSD:

<osd:ExtendedObjectSchema Name="DataTypesOSD"
xmlns:osd="http://schemas.microsoft.com/data/2002/09/20/persistencesch
ema">
<osd:Classes>
<osd:Class Name="Customer">
<osd:Member Name="Id" Key="true" />
<osd:Member Name="Company" />
<osd:Member Name="Name" />
<osd:Member Name="Phone" />
</osd:Class>
</osd:Classes>
</osd:ExtendedObjectSchema>

Not a whole lot here. Just a "Customer" object with some member
fields defined.

The Map:

<m:MappingSchema
xmlns:m="http://schemas.microsoft.com/data/2002/09/28/mapping">
<m:DataSources>
<m:DataSource Name="NorthwindRSD" Type="SQL Server"
Direction="Source">
<m:Schema Location="RSD.XML" />
<m:Variable Name="Customers" Select="Customers" />
</m:DataSource>
<m:DataSource Name="DataTypesOSD" Type="Object"
Direction="Target">
<m:Schema Location="OSD.XML" />
</m:DataSource>
</m:DataSources>
<m:Mappings>
<m:Map SourceVariable="Customers" TargetSelect="Customer">
<m:FieldMap SourceField="CustomerID" TargetField="Id" />
<m:FieldMap SourceField="CompanyName"
TargetField="Company" />
<m:FieldMap SourceField="ContactName" TargetField="Name" />
<m:FieldMap SourceField="Phone" TargetField="Phone" />
</m:Map>
</m:Mappings>
</m:MappingSchema>

This is where things get interesting! If you look carefully at the
map, there are two significant areas to consider. The data sources
tags define the locations of the RSD (source) and the OSD (target).
The mappings tag maps (literally) a source column to a target column.
Note that in some cases, the names are the same, but it is not
necessary that they are. Also note that the three XML samples are
cohesive, meaning that they were pulled from the same working sample.

In conjunction with the above XML schemas and maps, an ObjectSpace
namespace is used to enable the querying, interaction, and ultimately
consumption of the created objects.

And this is where my real knowledge ends, but certainly not my
enthusiasm for the technology. As an architect, I see a great deal of
potential in what I have described above, and I am on a personal
crusade to understand ObjectSpaces, with the intent of becoming an
evangelist once the organization that I work for adopts the new .Net
framework.


---
Waggs