Yukon & .Net v2

  • Thread starter Thread starter Guest
  • Start date Start date
G

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?
 
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
Click to expand...
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
Click to expand...
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
Click to expand...
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
Click to expand...
different properties in a production environment?
 
Back
Top