Каковы недостатки Typed DataSets

Question

Я родом из мира, который предпочитает строить свои собственные, а не полагаться на библиотеки и фреймворки, созданные другими. После выхода из этого мира я нашел радость и легкость в использовании таких инструментов, как Typed DataSets в Visual Studio. Итак, помимо потери гибкости, что еще вы теряете? Существуют ли коэффициенты производительности (без учета дебатов procs vs dynamic sql)? Ограничения?

Answer 1

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

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

Но вы получаете проверку типа времени компиляции, которая отличная, и такие вещи, как Customer.Name вместо Dataset.Tables (0) .Rows (0) («Name»).

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

Вы также можете изучить настоящую ORM.

Answer 2

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

Answer 3

Я подарил Typed Datasets очень короткую попытку. Я остановился, когда обнаружил, что мой код разбивается примерно на 2/3 пути вниз по 1000 + линейному файлу сгенерированного кода.

Другое, что мне не понравилось, я подумал, что мне удастся написать код типа Customer.Name, но по умолчанию я, похоже, получил код, например CustomerDataSet.Customers [0] .Name, где клиенты [0] был типа CustomersRow. Еще лучше читать, чем нетипизированные наборы данных, но на самом деле это не семантика, которую я искал.

Лично я направился по маршруту ActiveRecord/NHibernate и не оглядывался назад.

Answer 4

Основная критика, которую я хотел бы расширить, заключается в том, что они не масштабируются хорошо - производительность страдает из-за накладных расходов, когда вы получаете большее количество транзакций, по сравнению с легкими бизнес-объектами или DTO или LINQ to SQL. Также есть головная боль изменений схемы. Для архитектуры «промышленной силы» они, вероятно, не подходят, они в конечном итоге вызовут проблемы.

Я бы все равно определенно использовал их для быстрого и грязного PoC или простых утилит - они действительно удобны в работе с данным инструментом в Visual Studio и выполняют свою работу.

Answer 5

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

Есть несколько областей, где их преимущества уменьшающих:

• Я думаю, что вопросы синхронизации воспитаны здесь уже, безусловно, проблема, особенно если вы прошли и настроить их или использовать их в качестве базового класса ,
• В зависимости от количества таблиц данных в наборе данных, они могут стать довольно жир. Я имею в виду это в том смысле, что наборы данных с несколькими таблицами обычно представляют реляционный вид данных. То, что приходит вместе с этим, помимо объема памяти в памяти, - это определение ключей и потенциально других ограничений. Опять же, если это то, что вам нужно, но если вам нужно быстро проходить данные, один раз, то эффективный цикл с устройством чтения данных может быть лучшим кандидатом.
• Из-за их сложного определения и потенциального размера, использование их в ситуациях, связанных с удалением, также не рекомендуется.
• Наконец, когда вы начинаете понимать, что вам нужно работать с вашими данными в объектах, имеющих отношение к вашему проблемному домену, их использование становится скорее препятствием, чем преимуществом. Вы постоянно обнаруживаете, что вы перемещаете поля в и из строк таблицы в наборе и касаетесь себя состояниями таблиц и строк. Вы начинаете понимать, что они сделали языки OO, чтобы облегчить представление объектов реальной предметной области проблемы, и что работа с таблицами, строками и столбцами не подходит для такого мышления.

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

Answer 6

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

Answer 7

Я не большой поклонник типизированного набора данных. Я не могу улучшить производительность, используя типизированный набор данных. Это просто оболочка над существующими объектами базы данных. Я не могу рассматривать доступ как employee.empName. Кастинг все еще выполняется в обертке. Еще один накладной - огромный кусок кода. LOC увеличивается. Так много активных объектов в памяти. Нет автоматического обновления схемы. В любом случае типизированный набор данных не пригодится разработчикам, кроме комфорта, которое он дает. Как разработчики мы не имеем права требовать комфорта :) Возьмите боль ... возьмите боль от пользователя :)