I
I
Igor Mamushin2016-10-12 09:59:14
.NET
Igor Mamushin, 2016-10-12 09:59:14

Where to read information on data providers?

Где можно подробнее почитать про провайдеры данных?
Какие вообще есть современные провайдеры данных к реляционным БД?
ODP.NET это надстройка над ADO.NET?
Слышал что есть управляемые и неуправляемые провайдеры данных, в чем отличие?

Интересуют, как общие вопросы в данном направлении, так и конкретные для oracle, но с возможностью перейти на другую БД.

P.S. второй день сижу в поисковике и как то не удовлетворен результатом, может не там ищу.

Answer the question

In order to leave comments, you need to log in

1 answer(s)
S
Stanislav Makarov, 2016-10-12
@FatalER

ODP.NET is an add-on for ADO.NET?

Well, you have a mess in your head, no wonder you can't find anything.
ADO.NET is primarily a set of interfaces that allow you to write code that works with relational data in such a way that it depends minimally (or does not depend at all) on the specific DBMS used. ADO.NET is far from the first attempt to unify the interface for accessing databases (at least for relational ones), many large vendors did this, the same Borland.
Since the advent of dotnet as a platform, ADO.NET has been and remains the main way to access relational databases from dotnet applications. In most cases, there is no reason NOT to use it. It is worth noting that although now MS advises using an ORM (since the Entity Framework has matured) for data access, ADO.NET has not gone anywhere, because. all ORMs known to me also work through these interfaces.
There are many data providers, and the existence of each of the providers is determined by the existence of a particular DBMS. ODP.NET is not an add-on over ADO.NET, it is an implementation of ADO.NET interfaces that can interact with Oracle. Similar providers exist for other popular DBMSs, including PostgreSQL, DB2, MySQL, and even SQLite. In fact, the availability of a relational DBMS on dotnet is determined by the presence of a working ADO.NET provider.
Of course, a particular provider can add some specific functionality, but at the same time it must implement all the necessary interfaces. The trick of ADO.NET is that you can actually write such an application (of course, if you use only standard SQL constructs), which DOES NOT depend on a specific DBMS, to the extent that the necessary provider can be specified in the config file.
Most ADO.NET interfaces and classes are in the System.Data namespace . Conventionally, they are divided into the actual interfaces for accessing the database (the most important of them: IDbConnection , IDbCommand , IDataReader) and helper classes, in particular, a set of classes for organizing the simplest in-memory database inside your application, which will serve as a cache for data taken from the main database (the most important classes: DataSet , DataTable ).
I think it's about using or not using unmanaged code in the data provider implementation.
You can read about it in any normal dotnet book. If you have any questions, write in the comments.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question