Какие вопросы следует учитывать при выборе технологий доступа к данным?

Сроки и риск проекта. Это основы.

Я не очень хорошо знаком с LINQ или ADO.NET, но это не важно.

На высоком уровне я не вижу разницы между LINQ и ADO.NET. Я вижу, что LINQ «лучше», «элегантнее», меньше кода и понятнее. Но, по правде говоря, это не большие риски проекта, если команда уже знакома с ADO.NET и привыкла к ней. Вы по-прежнему будете получать свои данные в базе данных и из нее, и команда уже знает, как работать с ADO.NET «менее элегантно, больше кода, менее понятно» (помните, что это обобщения, а не суждения как таковые) .

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

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

Несмотря на то, что существует множество замечательных новых технологий, и они появляются каждый день, многое можно сказать о борьбе «дьявола, которого вы знаете», против принятия чего-то нового и недоказанного. Вот почему лично я провожу большую часть такого рода исследований в свое время, дома, в «режиме хобби», чтобы я мог быть лучше информирован о новых проектах, когда новая технология может быть подходящей и подходящей по сравнению с нашими проверенными и верными "олдскульные" методы.

В противном случае во время спецификации проекта необходимо выделить время для проверки новой технологии и определения ее пригодности для включения в начале проекта. Часто людям, составляющим спецификации, не дается это время.

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

Я стараюсь всегда следить за тем, что является передовым, чтобы знать, что там есть. Для этого нужно читать много блогов, посещать конференции и оставаться в курсе.

При этом вы не хотите всегда использовать все, что находится на переднем крае. Мое практическое правило - оценить дату отгрузки продукта. Я стараюсь использовать любую новейшую технологию, которая получила хотя бы один «пакет обновления» или обновление к дате, когда мы собираемся его отправить. Конечно, здесь много догадок, поскольку даты выпуска неизвестны, но опыт (в наблюдении за индустрией) очень помогает.

Есть искусство делать обоснованные предположения о том, какие технологии будут популярными, а какие со временем отпадут. К сожалению, это действительно вопрос опыта. Если у вас есть разработчик с многолетним опытом, который также всегда в курсе текущих технологий (важно), то они - хороший ресурс, который поможет в принятии этого решения.

Существует множество факторов, которые могут повлиять на то, какая технология «подходит» для данного решения или проекта разработки.

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

Принятие «правильного» решения, как я вижу, - это выбрать наиболее стабильное, задокументированное и работоспособное решение. Теперь, чтобы сделать это, вам нужно идти в ногу с технологиями и знать, что там есть. Поэтому необходимо поддерживать LINQ, Entity Framework и т. Д.

Настоящее «искусство» - это решить, что подходит для вашей среды, и каждая среда индивидуальна, у вас есть много разных вещей, которые нужно учитывать. Это только для внутреннего использования? Если нет, то какой у вас контроль и влияние на окружающую среду? Можно ли использовать самую последнюю версию VS и т. Д.

Я НЕ являюсь поклонником использования «передовых технологий» только потому, что это именно то, что нужно. Для использования новых инструментов необходима техническая база.

Переход на Linq-to-SQL после того, как проект уже начался, и когда не все были готовы, вероятно, было ошибкой, да. Даже если вы должны использовать его с самого начала, лучше придерживаться того, что вы знаете после запуска проекта. Другое дело - обратное: если вы пробуете что-то новое в начале проекта, и все идет плохо, может быть, лучше вернуться к чему-то более знакомому.

В случае Linq-to-sql маловероятно, что это даст вам преимущества, которые стоит перейти на него mid-project. Это была авантюра, и, к сожалению, похоже, что она не сработала.

Варианты доступа к данным .Net сводят многих из нас с ума. Ты не одинок. Даже пытаться узнать обо всех технологиях становится сложно. Чтобы правильно оценить, вы должны иметь опыт и тщательно исследовать. Вы определенно не хотите пробовать последнюю версию, потому что она кажется изящной. Некоторые из наших старых знакомых технологий (например, ADO.NET) работают нормально.

Имея 1-летний опыт работы, вы не виноваты в том, что изначально не выбрали правильную технологию. Подобные решения трудно принимать, и они приходят с опытом.

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

В половине случаев кажется, что это больше связано с использованием ресурсов, которые у вас есть (то есть, какие языки знают люди?) И на что у нас есть лицензии?

Использование «LINQ» не обязательно является «фантастической» идеей, будь то в начале или в конце проекта. Если ваша команда имела опыт работы с ADO.NET и успешно завершила проект с использованием этой технологии, то это действительно была технология, которую вы должны были использовать.

Дело в том, что если у вас есть команда, которая "знает" VB6 от и до ... ну угадайте, что ... вам больше нравится писать код на VB6.

Используйте технологии, которые удобны и хорошо осведомлены большинством команды (надеюсь, вы нанимаете именно на это).