Классическое ADO все еще жизнеспособно для смешанного управляемого / неуправляемого Приложения?

Question

У нас сложная архитектура с большим количеством логики в неуправляемом коде, который требует доступа к базе данных.

В настоящее время это происходит через драйверы ODBC и классы MFC, и мы рассматриваем вопросы миграции нашего уровня абстракции для использования ADO или ADO.Net. В последнем случае мы должны будем подтолкнуть логику базы данных обратно на уровень .Net. Я пытаюсь решить, компенсируется ли боль при вызове базы данных с помощью обратных вызовов .Net улучшениями в ADO.Net.

Сравнение в Википедии было интересным, хотя я не уверен, что считаю, что все пункты в таблице сравнения (например: ADO.Net всегда использует XML для передачи данных?).

A 2005 Сравнение показывает, что ADO.Net работает значительно быстрее.

Руководство Microsoft по ADO.Net для программистов ADO предполагает, что мы многое выиграем от перехода на ADO.Net, особенно благодаря тому, что данные доступны в собственных (.Net) типах, а не только через вариант OLEAutomation.

Answer 1

eg: does ADO.Net always use XML to pass data?

Нет. Звучит как идиотская информация в Википедии.

2 варианта. Во-первых, я бы ДЕЙСТВИТЕЛЬНО избавился от ODBC - и перешел бы, по крайней мере, на драйвер OleDb. Если возможно (скажите - у меня есть приложение .NET, использующее драйвер ODBC для вызова драйвера JDBC для вызова стороннего сервера приложений).

Теперь вы можете пойти обоими путями - ADO с обеих сторон, управлять ADO.NET и открывать данные из уровня NET - но это на самом деле не решение программиста, это архитектурная вещь, которую следует рассматривать в основном контексте. Возможно, я бы выбрал слой .NET, возможно, одновременно с уровнем экспозиции OData, и попытался бы использовать его из неуправляемого слоя.