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

Question

Были времена, когда нам приходилось выбирать между 2 или 3 технологиями / стратегиями для разработки модулей.

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

Иногда я расстраиваюсь из-за выбора доступа к данным в мире .NET. Мы не можем пойти и прочитать о каждом инструменте, который есть на рынке, и о том, что он может предложить, для каждого продукта.

Причиной возникновения этого вопроса является то, что недавно нам пришлось работать над проектом, и спецификации для DataAccessLayer были доработаны с помощью ADO.NET. Приблизительно на 20% пути к проекту новый разработчик присоединился к нашему отделу (но не к нашей команде). Я считаю его умным, полезным, и нам нравится работать с ним.

Во время проверки кода он лично сообщил нам, что для модуля, над которым мы работаем, лучше использовать LINQ to SQL. Он был убедителен. После положительного обсуждения мы согласились использовать LINQ to SQL.

Однако «менеджмент» не обрадовался этому. Был аргумент, что мы должны были придумать эту «фантастическую идею» перед запуском модуля. Их аргумент состоит в том, что ресурсы уже потрачены на 20% работы, и эта работа будет потрачена впустую.

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

Мы успешно использовали ADO.NET. У нас было представление о LINQ (в целом), NHibrnate и многих других, но мы пошли дальше ADO.NET. Я не против изучения новых вещей, поэтому мы все настаивали на использовании LINQ.

Вопрос Мы виноваты в том, что сделали этот выбор в то время, когда мы это сделали?

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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