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

Question

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

Answer 1

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

Answer 2

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

DataReaders быстрее, чем с помощью адаптеров ...

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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