Что является недостатками Введенного DataSets

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

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

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

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

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

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

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

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

, Но, Вы действительно получаете тип времени компиляции, проверяющий, который является большим и вещи как Клиент. Имя вместо Набора данных. Таблицы (0).Rows (0) ("Имя").

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

Вы могли также изучить реальный ORM.

Я только дал Введенным Наборам данных очень короткую попытку. Я остановился, когда я нашел свой код, повреждающийся о 2/3 пути вниз 1,000 + файл строки сгенерированного кода.

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

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

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

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

I'm not a big fan of typed dataset. There is no way that I can improve the performance using typed dataset. Its purely a wrapper over the existing database objects. I cannot consider the access like employee.empName. Casting is still done in the wrapper. Another overhead is huge chunk of code. LOC is increased. So many active objects in memory. No automatic update of schema. In any way typed dataset is not useful for developers except the comfort that it gives. As a developers we don't have any right to demand for comfort :) Take the pain...take the pain out of user :)