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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ни один человек не имеет всех ответов.

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

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

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

Ответ 10

Если Интероперабельность/будет проблемой вниз по линии, DataSet, безусловно, не правильное направление, чтобы идти. Вы можете выставить DataSets/DataTables за услуги, но вы должны или спорно ли. Если вы говорите .NET → . NET, вы, вероятно, хорошо, иначе у вас будет очень недовольный клиентский разработчик с другой стороны забора, использующего вашу службу.

Ответ 11

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

Ответ 12

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

DataReaders быстрее, чем использование адаптеров...

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

В любом случае: просто сделай это, попроси прощения, а не разрешения.

Ответ 13

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

Ответ 14

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

Работа выполнена.

Ответ 15

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

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

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

Ответ 16

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

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

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

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