Я должен обновить (хорошо, переписать действительно), МАЛЕНЬКОЕ приложение VB6, которое использует ADO для доступа к базе данных JET к приложению vb.net в Visual Studio 2008.
Мое исследование предлагает, чтобы я использовал LINQ, но это, кажется, не возможно подключить к СТРУЕ. Если СТРУЯ теперь удерживается от использования, что я должен использовать? Или я должен использовать ADO.NET без LINQ?
Не отвечайте на SQL Server! - это должно быть приложением, которое конечные пользователи могут установить легко в корпоративных или некорпоративных средах и не должны требовать никакого продолжающегося технического обслуживания. Я начал устанавливать SQL Express, но остановился, когда требовалось по крайней мере 2 системных обновления, поскольку это будет слишком сложно для этого небольшого приложения.
Jet устарел, но есть замена в виде ACE (Access Database Engine).
Однако, что касается его использования из LINQ. В ответах на этот вопрос есть различные предложения, и я также где-то читал, что для этого можно использовать LINQ to DataSet
. Вот сообщение в блоге об этом: Запрос наборов данных - Введение в LINQ to DataSet , но я не могу найти ссылку, где я читал, что кто-то успешно использовал его для доступа к базе данных Access.
Я бы посоветовал, если нет четкого решения для использования LINQ, прагматический подход заключался бы в том, чтобы просто придерживаться обычного ADO.Net и подождать с использованием LINQ, пока вы не будете уверены, что используете источник данных, который его полностью поддерживает.
Это может быть интересно:
Какой инструмент O/RM поддерживает Microsofts Access? http://blogs.msdn.com/b/adonet/archive/2007/01/26/querying-datasets-introduction-to-linq-to-dataset.aspx
Просто используйте объекты OleDbConnection
/ OleDbCommand
/ OleDbDataReader
для имитации той же логики, что и в коде VB6/ADO. Это будет работать точно так же и не потребует больше зависимостей, чем ваше существующее приложение.
Вот хороший бесплатный инструмент для обновления, если ваш проект содержит менее 10000 строк кода:
http://msdn.microsoft.com/en-us/vbasic/ff793478.aspx
Общий подход, которому вы должны следовать, это сначала чистая миграция с VB6 на VB.NET, и заставить версию .NET работать точно так же, как она работала в VB6, а затем начать искать альтернативные технологии в .NET. Легче переходить от одной технологии к другой, когда у вас есть работающее приложение .NET, чем вручную пытаться напрямую переходить от кода VB6 к альтернативам в .NET.
Вот несколько веских причин для того, чтобы сначала выполнить миграцию, а не переписывать приложение вручную:
5 причин, развеивающих мифы, для выбора автоматической миграции против ручной переписи
Из статьи:
Даже в худшем случае, когда вам все равно придется переписать определенную часть приложения после этапа автоматической миграции, конечный результат всегда будет в разы меньше общей стоимости и времени.