Yukon & .Net v2

[Guest]

Hola all,

I've been pretty excited reading about the object features that are going into the next version of SQL Server. In short, you will be able to natively add objects as User defined types and use them as you would within any other .Net assembly.

So what I'm looking for is some sort of best-practice document that explores the design implications of this. Any oo developer that does a lot of database-centric design has probably built a class factory that does nothing more than query the database and return instances of objects, as well as saves changes back to the SQL server. It would seem that Yukon can replace much of this tedium.

- What's the best way to go about this, in general
- Specifically (I'll use a class called Address for the sake of this discussion), should data be serialized in a single column of type [Address], the traditional column design (name, address, city, etc.), both, or other?
- How would one manage diferent releases of the Address class that exposed different properties in a production environment?

 

[Cor Ligthert]

Jon,
Erik,

I suggest to post this question to one of the Whidbey groups:

<URL:http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey>

Infos on how to view these groups with an NNTP news client:

<URL:http://communities.microsoft.com/newsgroups/ICP/whidbey/US/welcomePage.
htm>

--
Cor

I've been pretty excited reading about the object features that are going

into the next version of SQL Server. In short, you will be able to natively
add objects as User defined types and use them as you would within any other
..Net assembly.

So what I'm looking for is some sort of best-practice document that

explores the design implications of this. Any oo developer that does a lot
of database-centric design has probably built a class factory that does
nothing more than query the database and return instances of objects, as
well as saves changes back to the SQL server. It would seem that Yukon can
replace much of this tedium.

- What's the best way to go about this, in general
- Specifically (I'll use a class called Address for the sake of this

discussion), should data be serialized in a single column of type [Address],
the traditional column design (name, address, city, etc.), both, or other?

- How would one manage diferent releases of the Address class that exposed

different properties in a production environment?