Каковы недостатки Типизированных DataSets - PullRequest
17 голосов
/ 10 сентября 2008

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

Ответы [ 7 ]

14 голосов
/ 10 сентября 2008

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

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

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

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

10 голосов
/ 10 сентября 2008

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

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

5 голосов
/ 10 сентября 2008

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

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

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

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

Вы также можете заглянуть в настоящий ORM.

4 голосов
/ 10 сентября 2008

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

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

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

2 голосов
/ 13 декабря 2009

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

2 голосов
/ 10 сентября 2008

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

1 голос
/ 11 апреля 2009

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

...