The purpose of translation is to exercise E text, two is for learning, if this is any translation problem, please inform me (Mailto: Wonderf2100@sina.com or http://wonderf.blogone.net/)
Because I have limited essays, the error also please bear.
Original: http://www.15seconds.com/issue/040112.htm
Keywords: ORP ObjectSpaces object relationship lasting
.NET object relationship persistence mechanism
Chapter 1 About a new data access method
Introduction
At a few weeks ago, the loverierity of the .NET object relationship persistence is still in number. They believe that you can use a specialized data to eliminate those lengthy ADO.NET code and reduce business logic code from the application. In fact, most .NET developers, I hope I can write some data access layer (ADO.NET) code.
If you participate in the PDC meeting, you can learn from many clues to a new data access policy for Microsoft. In Whidbey and later Visual Studio, it will increase the ORP (object relationship persistence) function.
What surprises me is that many people participated in the Object-Relational Birds of A Feather (BOF) meeting hosted by Dave Foders. I originally expected that about 10 professionals who focus on ORP, discussing ORP, and current .Net Or Tools, talking their own experience. Unexpectedly, more than 100 people participated in this discussion. There are supporters, opponents, some interested people, and even some OR tools, the atmosphere is very enthusiastic. Objectspaces Team in Microsoft demonstrated ORP Framework in a crowded person.
Object Relationship This ability is not only for ObjectSpaces. You can find a lot of or (Object-Relational) traces in Microsoft's next SQL Server version yukon. YUKON can run the CLR-based code, use the stored procedures and CLR types written in the .NET language. Business objects can be passed to the stored procedure via the ADO.NET parameters, and then decompose into a relational structure by the .NET stored procedure code, in addition to this, the data column of the yukon table can be a complicated type of CLR. Assuming such a situation, a business object is passed as a parameter to YUKON, which can be kept as a column value to be saved to the database, which is more than decomposed into a relational structure.
Assuming in an application, there is a Person class to save your personal simple information, including ID, name, birthday
The following is the DDL definition of this Person table in SQL Server 2000
CREATE TABLE [DBO]. [Person] (
[ID] [INT] Identity (1, 1) Not NULL,
[Name] [varchar] (50) Collate SQL_LATIN1_GENER_CP1_CI_AS Not NULL,
[Birthday] NULL
) On [primary]
And you can write this in yukon:
CREATE TABLE [DBO]. [Person] (
[ID] [INT] Identity (1, 1) Not NULL,
[Person] NOT NULL
) On [primary]
The two main differences are: YUKON DDL contains a column of the Person type, and Person is a .NET object, obvious, in yukon you can customize a column of a .NET object type. In order for this Column to accommodate the CLR type, first of all this type will be compiled, then install it to SQL Server.
See an example of a Person class:
Using system;
Using system.data.sql;
Using system.data.sqltypes;
Using system.runtime.serialization;
Namespace Scottbellware.Personexample
{
///
/// REPRESENTS a Person.
///
[Serializable]
[SQLUSERDEFINEDTYPEATTRIBUTE (FORMAT.USERDEfined)]
Public Class Person
{
Private int ID;
PRIVATE STRING NAME;
Private datetime birthday;
Public Int ID
{
Get {returnim.
Set {this.id = value;
}
Public String Name
{
Get {return this.name;}
Set {this.name = value;
}
Public DateTime Birthday
{
Get {return this.birdhday;
Set {this.birdhday = value;
}
}
}
When this class is compiled into a DLL file, you can register it in SQL Server Yukon, this is the T-SQL statement registered DLL:
Create assembly personxample from 'c: /assemblies/scottbellware.Personexample.dll'
This creates this class in yukon, in nature, registers individual names for this class in Yukon, and yukon will reference this CLR type contained in the DLL. The column of the Person type is defined in the DDL table above, so you need to create this type in YUKON.
The code created is as follows:
Create Type Person
External Name [Personexample]: Person
You can insert a Person instance to the Person table using the parametric DML statement.
INSERT INTO PERSON (Person) VALUES (@Person)
If you have experience using the ADO.NET 1.x DataParameter object, the above DML statement may cause you curios. In ADO .NET 1.0, the DataParameter object can only package scalar values. The above command statement displays changes in SQLParameter Class in ADO .NET 2.0. You can pass the code to the database into the complex type.
A customized type of written code model into a customized type is similar to the ADO .NET 1.x DataParameter Objects. The database is incorporated into the scalar value.
In ADO .NET 2.0, the SQLParameter object instance is passed by reference, and the SQLParameter class adds a UDTTYPENAME attribute. Use this property to specify the SQLParameter instance to deliver a complicated type of packaging parameter name. Similarly, in the SQLDBTYPE enumeration type, the SqlDbType.udt type is also added to specify the value of complex types or user-defined types.
The following example demonstrates ADO.NET 2.0 client code to perform a query with complex parameters. Assume that there is already a SQLConnection object instance named Connection and a Person object instance called Person, and the database connection has been opened. // CREATE A Command from the Connection Object.
SQLCommand InsertCommand = CONECTION.CREATECMMAD ();
// Assign the dml to the commit command.
INSERTCOMMAND.COMMANDTEXT = NSERT INTO PERSON (PERSON) VALUES (@Person)?
// Parameter Object to Encapsulate The Person Instance.
SQLParameter Parameter = INSERTCOMMAND.PARAMETERS.ADD (Person? Sqldbtypes.ud);
// set the Type Name of the parameter 抯 Encapsulated complex type.
Parameter.udtTypename = COTTBELLWARE.PERSONEXAMPLE.PERSON?
// Assign The Person Instance to the parameter 抯 Value.
Parameter.Value = Person;
// Execute the commit.
Command.executenonQuery ();
From a long time, Longhorn will bring us in the platform level. Longhorn's file system is based on the next generation of SQL Server technology, while ObjectSpaces will play a critical role in the LONGHORN API.
You will see the object relationship persistence mechanism in Microsoft will be published in MBF. MBF provides an abstract mechanism to describe business objects and business processes for creating business applications, while it can also be held by ObjectSpaces.
Object Relations Persistence is rarely used in traditional data access, and applied in .NET's data access mode and mechanism. The .NET data access commands and results are passed through the API of the data access layer, even if these are in an architecture lastled in an object. Object Relations Persistent Architecture Extracts the underlying API and ADO.NET to extract the underlying local client library using a similar approach, and the client code becomes clearer, readable.
