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

Большинству программистов не нравится отклоняться из их зон комфорта (обратите внимание, что пересечение 'большинства программистов' набор и набор 'Переполнения стека', вероятно, пустое множество). "Если это работало, прежде (или даже просто работал) тогда продолжают делать его". Проект я в настоящее время нахожусь на необходимом много аргумента, чтобы заставить программистов старшего возраста использовать наборы XML/schemas/data вместо просто файлов CSV (предыдущая версия программного обеспечения использовала CSV). Это не прекрасно, схемы не достаточно устойчивы при проверке данных. Но это - шаг в правильном направлении. Код, который я разрабатываю, использует абстракции OO на наборах данных вместо того, чтобы раздать объекты набора данных. Обычно лучше преподавать примером, один маленький шаг за один раз.

Если можно представить, просто Сделайте это и профиль. Наборы данных более тяжелы тогда простое Collection<T>

, DataReaders быстрее тогда используют Адаптеры...

Изменяющееся поведение в объекты намного легче, чем массирование набора данных

Так или иначе: Просто Сделайте Это, попросите прощения не у разрешения.

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

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

Не делайте его обсуждение веры или религия. Тех трудно выиграть (и не то, что Вы хотите так или иначе)

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

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

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

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

Настоятельно рекомендуют, чтобы я мог дать, должен использовать его так, как Вы можете в своем собственном коде, и надо надеяться через экспертные оценки и bugfixes, другие разработчики будут видеть, как код становится более читаемым. (удостоверьтесь, что продвинули точку, когда эти случаи произойдут).

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

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

Временно назначенный. Вся эта мысль, от которой "развитие предпринимательства" так или иначе отлично (и обычно импликация 'более важна, чем') нормальная разработка действительно раздражает меня.

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

необходимо быть реалистичными при создании этого списка. Вы не можете только сказать, "Сохраняет нас много времени!!! WIN!!" не обращаясь к тому, что иногда это собирается занять БОЛЬШЕ времени, потребует, чтобы X месяцев подошли к скорости на новой технологии и т.д. Необходимо показать конкретные примеры, где это сэкономит время, и точно как.

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

BTW. Высматривайте этот конкретный довод "против". Это превзойдет все, если Вы не будете иметь партия из веских доводов в пользу всего Вашего другого материала:

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

Сделайте это примером и шагом слегка. Что-либо более сильное будет просто отчуждать Вас от остальной части команды.

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

ни у Какого единственного человека нет всех ответов.

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

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

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

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

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

Два месяца связи для фиксации хаотической путаницы я взял его на меня для перепроектирования всего модуля в объектно-ориентированный график для решения этой проблемы . yeap, вместе с абстрактными классами (для рендеринга различного управления ответом на ячейке сетки в зависимости от типа вопроса), делегаты и обработка событий. Конечным результатом был 2D dataGrid binded к глубокой иерархии вопросов, естественно отсортированных согласно родительско-дочернему расположению. Когда ответ родительского вопроса изменился, он сгенерировал бы событие к вопросам о детях, и они автоматически покажут/скроют свои строки в сетке согласно ответу родителя. Только вопрос возражает вниз, что путь был затронут. Скорость отклика UI этого решения по сравнению со старым методом была порядками величины.

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

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

Технический выбор всегда включает компромиссы между за и против доступных параметров. Центральный набором данных подход имеет свои преимущества (подобное таблице базы данных представление в оперативной памяти фактических данных дб, классы, записанные людьми, которые знают то, что они делают, знакомый большому бассейну разработчиков и т.д.) также как и пользовательские объекты данных (проверка типа компиляции, пользователи не должны изучать SQL и т.д.). Если все остальные в Вашей компании идут путем DataSet, по крайней мере, технически возможно, что DataSets являются лучшим выбором для того, что они делают.

Уже существует некоторый очень хороший совет здесь, но у Вас все еще будет задание для убеждения коллег, если все, необходимо создать резервную копию Вас, будет несколькими поддерживающими комментариями stackoverflow. И, если они так скептичны, как они звучат, Вы испытываете необходимость в большем количестве боеприпасов. Во-первых, получите копию "Шаблонов Martin Fowler Архитектуры предприятия", которая содержит подробный анализ множества методов доступа к данным. Считайте его. Затем вынудите их всех считать его.

сделанный Job.

Если Совместимость/, беспокойство по линии, DataSet является определенно не правильным направлением для входа. Вы CAN выставляет Наборы данных/Таблицы данных по сервису, но должны ли Вы или спорны. Если Вы говорите.NET->. СЕТЬ Вы, вероятно, в порядке, иначе Вы собираетесь иметь очень несчастного разработчика клиента с другой стороны забора, использующего Ваш сервис

ориентированность на данные означает меньшую сложность кода.

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

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

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

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

Итак Я написал приложение для автоматизации процесса сборки. У него был элементарный пользовательский интерфейс WinForms. Но поскольку мы двигались в сторону WPF, я изменил его на пользовательский интерфейс WPF, сохранив пользовательский интерфейс WinForms, благодаря Model-View-Presenter. Для тех, кто не был знаком с Model-View-Presenter, это был легко понятный пример, на который они могли сослаться.

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