Microsoft's thinking about OLE DB and. NET
You and I are not acquainted. But in the face of a real problem, "What is software?" "I don't have the right answer," he said.
Imagine a scene where you're concentrating on buying useless things (mainly souvenirs) in a souvenir shop, so you can be happy to meet your friends and relatives at the airport. At this time, often someone will ask you: "The first time?" A business trip or a vacation? ”
So if you're doing software-related things, not on vacations, you have to face the real problem.
So, what exactly is the software?
It is difficult to answer this question about existence, especially if you are wandering, carrying a backpack postcard, koala pictures and kangaroo toys with a yellow amber warning sign on the bag.
I try to make my mind free and as simple as possible. First, the software is related to the computer. Software is also associated with evolution. Of course, software is also related to data (especially data storage and operations).
Back at the hotel, I was still thinking about the following question--about the storage and use of data, what have I observed in recent years? So I started thinking about OLE DB and its evolution in. NET.
Software evolution
Historically, ODBC made its first serious attempt: it tried to create a unified approach to accessing a database for applications. Like everything else in the software, ODBC is designed to meet a specific need. It has created a new phase in the never-ending process of information technology evolution.
ODBC must provide a common (preferably abstract) API to access the database without regard to the internal details of the database, the language, and the organization of the table. Over time, however, it has been found that, in the face of new data-driven application design and construction methods, ODBC is increasingly unable to successfully meet the needs.
Software also has its own theory of evolution. ODBC adapts to change with different names, different programming models, and new features, and survives, while maintaining its true mission. ODBC continues to provide (or more or less) the functionality of an open database connection with the name and functionality of OLE DB.
OLE DB, as a programming interface, applies the theoretical concepts of Microsoft Universal Data Access (UDA) policies to practice. UDA is able to access various types of data, including relational, non-relational, and hierarchical data, through a single programming interface based on COM.
OLE DB is designed as a component technology and is characterized by a multi-tier model. On one side of the COM bridge is the server component that retains the data, and the other side is the client component that understands how to connect and request data. The former is called an OLE DB data provider, while the latter is called an OLE DB consumer.
Both the consumer and provider are COM objects and can communicate with each other through a set of COM interfaces. This COM based communication can be summed up in abstract objects such as
DataSource、
Session、
CommandAnd
Rowsetis performed. Therefore, when the user connects to the
DataSourceOpen it
SessionIssued
Command, and returns the data
Rowset, this situation will occur.
This evolution of ODBC enables UDA and OLE DB to add a feature that, like a simple relational table, glues all enterprise data together, whether they are relational, not relational, or hierarchical.
OLE DB Model
When it comes to data access, we have two basic choices. One is to adopt a universal data access strategy, as UDA allows. The other is inclined to use a common data structure. It forces all existing information to be moved from the current data store to a database server that can contain all data types.
With OLE DB, you need to glue all of your customer information together. Alternatively, the client is forced to upgrade to a new, more powerful, unique DBMS that can handle any form of information.
Compared with ODBC, OLE DB relies less on the physical structure of data. In addition, it does not have to be strictly based on SQL. OLE DB commands can be SQL statements or something else. In general, they can be seen as text strings written in any syntax that can be understood by the target provider.
Like ODBC, OLE DB is designed with the concept of C + + to maximize the performance of middle-tier module data access. For the same reason, OLE DB cannot be used directly in Visual basic® or ASP.
Countless distributed systems use Visual Basic to generate components. This is the main reason Microsoft introduced the ActiveX® data Object (ADO) library.
The programming interfaces of ADO are richer than the original OLE DB SDK. Although it is entirely feasible to use ADO in C + + applications, OLE DB calls go through fewer levels of code and can reach data more directly than the corresponding ADO code.
Although ADO is obviously generated on OLE DB, invoking the original OLE DB interface and the calls made while running through ADO has a different relative speed. This fact leads to differences between languages. Which one is better and more worthy of recommendation? is the C + + high-performance level of OLE DB or a simpler, friendlier ADO model in the Visual Basic component?
In addition to providers and consumers, the OLE DB model includes a third element--ole db service. A service is a COM component that handles the rowset that is returned to the consumer. It works like a hook, overseeing all communication between the user and the provider. ADO relies heavily on OLE DB services to add its extended functionality, such as data plasticity, persistence, and fractured recordsets.
As a result, since people began to focus on building COM-based distributed applications, a variety of best practices have been developed for specific areas. To improve the scalability of WEB applications, people instead use data access fracture models.
Simply put, data consumers and data providers are not always connected. Once a connection is established, you can emit the specified query, get the record and put it in an in-memory repository, and then disconnect from the data source. You then process the records offline and reconnect or commit the changes if needed. This model is not available in all cases, but once it does work, you'll find it valuable in terms of scalability and overall performance.
Many systems have been converted (or converted) to enable data disconnection through the client Cursor service to deploy an ADO recordset. OLE DB is not yet a model dedicated to this type of interaction, so ADO is extended through intermediate OLE DB services.
Because of the flexibility inherent in its structure, OLE DB can be successfully applied to disconnected scenarios, but this certainly does not represent the best way to work. Another small limitation of this implementation is that scenarios rely heavily on ADO recordsets to work, so that people suspect that it is impossible to always do everything well. How can such an object become the fastest working tool in all cases, whether it's connected or disconnected, is there XML, created or loaded from disk?
In addition, the use of OLE DB will result in significant inconsistencies, considering that the functionality package for ADO is significantly different from the original OLE DB SDK.
As a result, Ado.net becomes the next step in the evolution of data access technology. However, from the name's perspective, Ado.net seems to be just an inheritor of ADO. What about OLE DB in. NET?
. NET Managed Providers
The timeless theory of evolution the OLE DB technology is now pushed forward to meet the requirements of the new user. In. NET, a WEB application is first and foremost a disconnected application that uses the special tools of the new design to manage the data.
The. NET framework enables classes to handle data. These classes-especially the ado.net and XML namespaces-are available for collection, reading, and writing. The ado.net and XML subsystems eventually replaced the ADO and OLE DB SDK. Now you have a unique, language-centric approach to getting and setting data.
The Ado.net class is even better at abstracting the data source than ADO because it is explicitly designed to be data-centric, while ADO still uses a database-centric design.
The portion of. NET that corresponds to the OLE DB data provider is called the managed provider. Their role is shown in the following figure.
Figure 1: Managed provider hierarchy Diagram
In OLE DB, two layers of interaction can be identified by similarity, that is, the managed consumer layer and the managed provider layer I mentioned above. When working with data,. NET applications do not have to use special classes or components as consumer modules.
If the. NET application uses only the
DataSetOr
DataReaderobject, it becomes a "managed" data consumer immediately. To really get the data, you should use the
DataSetCommandAnd
DbCommandGets an instance of the special class inherited from the These classes represent a link to the data source.
Instead of directing generic objects to handle a given provider, you simply use an export class that understands how to handle a given provider. So what happens is that
SqldatasetcommandThe SQL Server database will be processed, and
AdodatasetcommandAll existing OLE DB providers will be wrapped.
The managed provider will be hidden in such a DataSetCommand class. You never realize that they exist, nor do you need to know them specifically. Just use the class and set the properties, which makes people feel happy.
In this case, the interaction modules used by the managed provider layer in the previous illustration are not much different from the modules used in OLE DB or even earlier ODBC. The consumer command class is for a specific component that wraps a data source. It understands the protocols used to read and write data rows in the source. It also returns results in a format that a. NET class can handle well.
For ease of understanding, let's review the commonality of OLE DB and. NET data retrieval.
OLE DB Provider
. NET Managed Providers
IdentificationCOM ProgID wrapped in a command class
return ResultsRowset or ADO recordsetdataset or DataReader classes
Update modeSpecial commands for the provider's special commands
transfer FormatBinary XML
Table 1: Comparing OLE DB and. NET Data Providers
The target provider is identified by its COM ProgID in OLE DB, and in. NET, the details are hidden in the accessor class.
OLE DB providers always return rowset--com objects primarily provide
IRowsetInterface. If you access data through ADO, a rowset is converted to a richer and more scripted object, called a recordset.
. NET applications use only a variety of classes that have different functionality.
DataReaderA class is a simple, fast, forward-only cursor that works in a connection state and provides access by record. You must explicitly disconnect after the end of the connection. Instead
DataSetObject is an in-memory disconnected collection table. It is
DataSetCommandThe instance of the fill of the class.
DataSetobject is based on the contents of the
DataSetCommandBased on the XML stream retrieved from the data source.
In a future column, I'll tell you about
DataReaderAnd
DataSetThe content.
The data arrives in binary format from the provider to the consumer, and if OLE DB is deployed, it is also passed through a COM configuration. In. NET, the managed provider returns an XML stream.
Both providers support query languages (typically SQL and individual vendor-specific extensions). The language allows you to perform updates and ask for a data source.
So what is the difference between an OLE DB data provider and a. NET data provider? In abstract, they use the same data access policy. But hosting providers are simpler and more professional. Two main reasons lead to the superiority of its performance. First, the managed provider does not use the COM Interop Bridge to get and set the data. As a COM component, the OLE DB provider has no choice at this point. Second, a managed provider typically takes advantage of the vendor's internal data source knowledge to get and set rows faster. OLE DB providers do the same, but when used within. NET, OLE DB providers must pay for their COM-based attributes and require additional code to convert the data to. NET-specific classes.
Existing managed providers
As in Beta 1, the NET framework features two managed providers: one for SQL Server (version 7.0 or higher) and one for all data sources that can be obtained through OLE DB providers.
SQL Server managed providers are hidden in a particular class, such as
SQL DataReader、
SQL DataSetCommandAnd
SQLCommandAfter These classes direct access to low-level SQL Server file systems. The following figure is the provider's class diagram. The diagram maps the previous generic schema to the SQL Server hosting provider.
Figure 2:sql Server Managed Provider Class diagram
The role of OLE DB managed providers in. NET is the same as for ODBC OLE DB providers in the Windows DNA system. Simply put, it reflects the fact that all. NET applications can be targeted to any existing data source based on OLE DB. The class diagram for the OLE DB managed provider is shown below.
Figure 3:ole DB Managed Provider Class diagram
Please note that in Beta 2, the Adoxxx class needs to be renamed to Oledbxxx.
The OLE DB managed provider supplies the. NET class to the caller, but uses the specified OLE DB provider to fetch the rows. Communication between the. NET application and the underlying OLE DB provider (COM object) occurs through the COM Interop Bridge.
In general, a table of SQL Server 7.0 (and later) can be accessed by both providers in. NET. The managed provider of SQL Server requests data directly from the DBMS file system, while the OLE DB managed provider relies on the services of the SQLOLEDB OLE DB provider, resulting in the need for additional levels of code.
Now, if you are dealing with any data source other than SQL Server, the OLE DB managed provider is the only channel. Through the same channel, you can also reach any ODBC data source.
OLE DB managed providers are thin wrappers that are generated on the COM interop Bridge and can be transferred to the local OLE DB provider. In addition to setting and terminating calls, this module is also responsible for wrapping the returned rowset to the
DataSetOr
ADO DataReaderObject for subsequent. NET processing.
At the. NET code layer, accessing the SQL Server table through a local managed provider or OLE DB provider actually changes the prefix of the class involved. The following are the code for SQL Server:
Dim strconn, strcmd as Stringstrconn = "database=northwind;" Server=localhost; Uid=sa; pwd=; " Strcmd = "SELECT * from Employees" Dim ocmd As New Sqldatasetcommand (Strcmd, strconn) Dim ODS As New Datasetocmd.filldataset (ODS, "employeeslist")
The following is the code for the OLE DB provider (different in bold):
Dim strconn, strcmd as Stringstrconn = "database=northwind; Server=localhost; Uid=sa; pwd=; " Strcmd = "SELECT * from Employees"Dim ocmd As New Adodatasetcommand (Strcmd, strconn)Dim oDS As New datasetocmd.fi Lldataset (ODS, "employeeslist")
This shows that the surface difference is very small; only the connection string differs from the command class. The difference between using one class or another is very large.
The existence problem of OLE DB
The. NET managed provider represents the next step in the evolution of data access technology, but there is no documented SDK in Beta 1 that involves a data source-specific hosting provider. Several basic questions about OLE DB and. NET are not negligible. They are waiting for Beta 2.
Are all the code developed for OLE DB just obsolete code? What will be the effort of all the companies that have invested (and are often still putting) for their own data-writing providers?
Stick to your faith.--ole DB is not a technology that is extinct. In particular, it is still the basic specification for a rich, versatile, and stand-alone programming interface that is independent of. NET. It is not specifically for. NET, but it is well supported.
This means that if you want to expose your custom data, you cannot ignore the presence of. NET and managed providers. So what is the best interface for packaging data providers? How should you plan to disclose your data as soon as possible? For example, starting next Monday 8 o'clock in the morning?
. NET uses open standards and is widely based on XML. In this case, if you need to expose data that is proprietary and text-based, you only need to consider using XML (possibly a custom scheme) for publishing. There are so many tools in. NET that work with XML data, and the generation of wrapper classes should be completely free of problems.
For more complex data storage, OLE DB providers are still meaningful because your user base is larger and may not be limited to. NET. Hosting providers can certainly provide a huge performance advantage for. NET-proprietary applications, but I am very cautious about this-especially in such a short time to make a decision! Don't forget that no SDK has been released so far about the hosting provider, even though Microsoft has made that commitment.
Anyway, the next data provider I'm going to start writing this Monday morning will include a pair of OLE DB data providers and a. NET wrapper class that uses XML. My first choice is not to wrap an OLE DB provider with a. NET class through COM Interop. I prefer to use the same, adjusted source code. In this case, managed C + + is likely to be the best language for reusing "physical" code.
The end of OLE DB
Let's use this as a prophecy to be validated in the coming years from now. I would venture to say that OLE DB will, like SGML (standard generic Markup Language, the predecessor of XML), end up being less than ideal.
The introduction of SGML, the Savior of the world of data exchange, has never been a de facto standard, perhaps because it is too powerful and complex for everyday use. The fact is that its exciting principles have been appropriately reduced and specialized, and that XML has been generated before it is widely accepted.
My prediction is that once. NET builds on its foundation, OLE DB will gradually lose its importance until it finally disappears. I'm not sure how long this process will last, but I'm sure it is.
The argument is in the back <g>. Don't go away.
Dialogue: Yes, now I feel out of date
you are probably living in another time and space! How do you define existing ADO code as stale (in most cases, the code is written within six months). ）？ In the name of the. NET Technology/platform? It has not even entered the second phase of the Beta program.
What's life like without any focus? In any case, this question is well asked.
In the face of many recent ADO codes in DNA systems, can we define them as stale code? My answer is still: "Yes, we will." "But I do understand that this sounds really confusing."
I think that "stale code" is the code that no longer fits the core of the hosting platform. Believe me, this is really the situation that. NET is about to face. Of course, there are ways to combine existing code, components, and applications in. NET.
. NET is a non-violent revolution, and in the years to come, it will draw on any viable example of Windows software. Resistance is futile-you are destined to be assimilated. Regardless of the age of the code, what really matters in my definition of "stale" is the consistency of the source code with the runtime.
. NET changes the Windows runtime so that it is hosted. Although COM and the Windows SDK are not completely out of life, you must write code based on another model. Whatever the basis of this new runtime, a brand-new model will compete with the old model. This new model will be a model for future Windows.
Windows will not perish, but it will change. COM will not perish, but it will have to face. NET classes. ADO will not perish and will continue to play a role, but the ado.net feature of. NET is the future of ADO.
. NET is not simply that Windows 6.0,ado.net is not a wonderful new name formerly known as ADO 3.0. It is different and universally applicable. It's the new platform. Other content is either a different platform or a stale code (when integrated).
Stale code is the time that exists. I know people will still be writing DNA systems in this week, within six months, even after. NET was released. I am not saying that this is completely wrong or should be absolutely avoided. Just to remind you that you are moving against the tide.
