Как убедить моих коллег не использовать наборы данных для развития предприятия (.NET 2.0+)

Question

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

Answer 1

Сделайте это на примере и действуйте легко. Все, что сильнее, просто оттолкнет вас от остальной части команды.

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

Ни у одного человека нет ответов на все вопросы.

Answer 2

Если вы работаете с устаревшим кодом (например, приложениями, портированными из .NET 1.x в 2.0 или 3.5), было бы плохой идеей отказаться от наборов данных. Зачем менять то, что уже работает?

Однако, если вы создаете новые приложения, вы можете сослаться на несколько вещей:

• Призыв к испытанию боли в поддержке приложений, которые придерживаются DataSets
• Приведите преимущества производительности для вашего нового подхода
• Приманка с хорошей серединой. Перейдите на .NET 3.5 и, например, продвигайте LINQ to SQL: все еще придерживаясь архитектуры, управляемой данными, это огромный, огромный отход от наборов данных, индексированных по строкам, и обеспечивает ... вуаля! Пользовательские коллекции - таким образом, что скрыты от них.

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

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

Answer 3

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

Откомандирован. Сама идея о том, что «развитие предприятия» каким-то образом отличается от (и, как правило, подразумевается «важнее, чем») нормального развития, меня действительно раздражает.

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

Вы должны быть реалистами при создании этого списка. Вы не можете просто сказать "Спасает нас много времени !!! ВЫИГРАЙ !!" без учета того факта, что иногда это займет БОЛЬШЕ времени, потребуется X месяцев, чтобы освоить новую технологию и т. д. Вам нужно показать конкретные примеры, где это сэкономит время, и как именно.

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

КСТАТИ. Ищите этот конкретный мошенник. Это превзойдет все, если у вас нет лота сильных кейсов для всего остального:

• Требуется 12+ месяцев работы по переносу существующего кода. Вы проигрываете.

Answer 4

Конечно, «это зависит» от ситуации. Иногда DataSets или DataTables больше подходят, например, если это действительно легкая бизнес-логика, плоская иерархия сущностей / записей или некоторые возможности управления версиями.

Пользовательские коллекции объектов светятся, когда вы хотите реализовать глубокую иерархию / график объектов, которые не могут быть эффективно представлены в плоских 2D таблицах. То, что вы можете продемонстрировать, - это большой граф объектов и заставление определенных событий распространяться по правильным ветвям, не вызывая неподходящие объекты в других ветвях. Таким образом, нет необходимости зацикливаться или выбирать все данные в DataTable только для того, чтобы получить дочерние записи.

Например, в проекте, в котором я участвовал два с половиной года назад, был модуль пользовательского интерфейса, который должен отображать вопросы и элементы управления ответами в единой сетке данных WinForms (точнее, это UltraGrid от Infragistics) , Еще несколько хитрых требований

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

Первоначальная реализация была полностью написана в DataSets, DataTables и массивах. Количество циклов в сотнях строк для нескольких таблиц было просто изумительным. Это не помогло программисту, пришедшему из C ++, пытаясь ref все (привет, объекты, находящиеся в куче, используют ссылочные переменные , как указатели!). Никто, даже изначально программист, не мог объяснить, почему код делает то, что делает. Я появился на сцене более чем через шесть месяцев после этого, и он все еще был залит жуками. Неудивительно, что разработчик 2-го поколения, от которого я вступил во владение, решил уйти.

Два месяца работы по исправлению хаотического беспорядка, я взял на себя задачу перепроектировать весь модуль в объектно-ориентированный граф для решения этой проблемы . да, в комплекте с абстрактными классами (для визуализации различных элементов управления ответами в ячейке сетки в зависимости от типа вопроса), делегатами и событиями. Конечным результатом была двумерная сетка данных, связанная с глубокой иерархией вопросов, естественно отсортированных в соответствии с порядком родитель-потомок. Когда ответ родительского вопроса изменился, это вызвало бы событие у дочерних вопросов, и они автоматически отобразили / скрыли свои строки в сетке в соответствии с ответом родителя. Были затронуты только объекты вопроса, находящиеся на этом пути. Реагирование пользовательского интерфейса этого решения по сравнению со старым методом было на порядки.

Answer 5

Как ни странно, я хотел опубликовать вопрос, который был полной противоположностью этому. Большинство программистов, с которыми я работал, использовали подход пользовательских объектов / коллекций данных. Мне больно смотреть, как кто-то с открытым определением таблицы SQL Server на одном мониторе, медленно набирает соответствующий класс-оболочку строки в Visual Studio на другом мониторе (в комплекте с закрытыми свойствами и установщиками-получателями для каждого столбца). Это особенно больно, если они также склонны создавать таблицы из 60 столбцов. Я знаю, что есть системы ORM, которые могут создавать эти классы автоматически, но я видел, что ручной подход используется гораздо чаще.

Инженерные решения всегда включают компромиссы между плюсами и минусами доступных вариантов. Подход, ориентированный на DataSet, имеет свои преимущества (представление в реальном времени данных в формате db в виде таблиц в памяти, классы, написанные людьми, которые знают, что они делают, знакомы большому кругу разработчиков и т. Д.), Как и пользовательские объекты данных (проверка типа компиляции, пользователям не нужно изучать SQL и т. д.). Если все в вашей компании идут по маршруту DataSet, технически возможно, что DataSet - лучший выбор для того, что они делают.

Answer 6

Наборы данных / таблицы не так уж и плохи, не так ли?

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

В конечном счете, если код работает, остальное - семантика, на мой взгляд.

Answer 7

Если совместимость является / будет проблемой в будущем, DataSet определенно не является правильным направлением. Вы МОЖЕТЕ выставлять DataSets / DataTables через службу, но независимо от того, ДОЛЖНЫ ли вы или спорны. Если вы говорите .NET -> .NET, вы, вероятно, в порядке, иначе у вас будет очень несчастный клиент-разработчик с другой стороны забора, потребляющий ваш сервис

Answer 8

Не делайте это религией или обсуждением веры. Это трудно победить (и это не то, чего ты хочешь)

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

У меня были разработчики, использующие dataTables для хранения данных, которые они выбирали из базы данных, а затем код бизнес-логики, использующий этот dataTable ... И я показал им, как я сократил время загрузки страницы с 7 секунд загрузки 100% CPU на веб-сервере), чтобы вообще не видеть движения ЦП .. путем изменения объекта памяти с dataTable на хэш-таблицу.

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

Answer 9

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

Answer 10

Полагаю, вы можете попытаться продать идею O / R mapping и mapper tools. Преимущество обработки строк как объектов довольно велико.