Кто-нибудь использует типизированные DataSets в .NET?

Question

Я однажды пытался использовать типизированные DateSets в относительно небольшом производственном приложении. Изначально это выглядело довольно неплохой идеей, но оказалось другим. Это было довольно хорошо для некоторых базовых задач, но как только понадобилось что-то более продвинутое, его ограничения вступили в силу и с треском провалились. К счастью, проект был отменен, и теперь я стараюсь придерживаться правильного ORM, такого как NHibernate.

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

Добавлено:

Не могли бы вы также быстро объяснить, как вы их используете?

Я пытался использовать их в качестве своего DAL - это были приложения Windows Forms, и он извлекал данные из таблиц в DataSet, а затем манипулировал данными, прежде чем вызывать функцию иерархического обновления TableManager (не помню точного название). DataSet имел одну таблицу для каждой из физических таблиц БД. Проблемы начались, когда мне пришлось сделать что-то вроде отношения мастер / детали, где я должен был вставить сразу несколько записей (одну основную запись и несколько записей подробностей) в несколько таблиц, сохраняя при этом правильность внешних ключей.

Добавлено 2:

О, и если вы используете их, то где вы разместите свою бизнес-логику? (Валидации, расчеты и т. Д.)

Answer 1

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

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

Нормальная строка oRow["row_pk"]

В наборе типизированных данных теперь он становится: oRow.row_pk

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

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

Вернувшись, когда .NET был еще 1.1, я прочитал книгу Дэвида Счеппы по ADO.NET , это открыло мне глаза на то, чего можно достичь, и значительно упростило мой DAL (с использованием наборов данных ). Там есть много методов, которые действительно могут помочь улучшить ваш код, я очень рекомендую его.

Answer 2

Я использую их, когда: 1) Написание «1-off», которые будут отменены после завершения проекта, над которым мы работаем. 2) Использование XML-файлов для обмена данными с другими поставщиками. 3) Прототипирование и тестирование,

У меня были проблемы с набранным набором данных, когда: 1) Сложные запросы необходимы для фильтрации и сохранения данных. (по крайней мере для меня) 2) Недостаточное знание того, что дизайнер Visual Studio пишет от моего имени, чтобы я мог расширить производный класс, созданный для типизированных наборов данных.

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

С уважением,

Debug

Answer 3

Мне было полезно создавать XML-документы для отправки в веб-службу. Клиент определил ожидаемые данные как типизированные DataSets, что позволило очень просто создать DataTable в памяти и получить представление XML.

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

Answer 4

Я их использую, но не в обычном смысле. Это похоже на ответ ocdecio, хотя в моем случае это как презентационная модель (без адаптеров таблиц) в asp.net

Уровень «клиентские услуги» использует их (как часть договора) для любого метода, который принимает или возвращает данные. Базовые бизнес-сервисы используют более традиционный подход poco, а клиентские сервисы просто делают небольшое сопоставление для создания строго типизированного набора данных для данного пользовательского интерфейса.

Поддержка инструментов значительно упрощает для новых разработчиков (которые могут следить за видео asp.net/learn для ускорения работы) использование услуг, которые им требуются. Разработчики пользовательского интерфейса также могут быстро «спроектировать» новый набор данных, которые они хотели бы получить, и получить оттуда команду соответствующей службы.

Answer 5

Они именно то, что требуется, если вы верите в пользу программного обеспечения написания программного обеспечения, и статическая типизация - программное обеспечение ловя ошибки программного обеспечения - за счет eomplexity (точно), накладные расходы развития (возможно) и эффективности (возможно, но спорно ) - что является основной предпосылкой языков, таких как C # и Java.

Это, однако, еще не полностью выигранная битва.

РЕДАКТИРОВАТЬ (запрошенное объяснение):

Сложность.

Используя либо C #, либо Java, вы получите много кода для настройки, объявления типов, приведения типов, проверки типов и проверки. Некоторые из них вы пишете сами, некоторые из IDE пишет для вас. Но это весь код, за который отвечает разработчик. Основные преимущества для IDE / компилятора - указание на возможные ошибки программного обеспечения и автозаполнение. Я могу с уверенностью сказать, не принимая ни одной из сторон, что в отрасли ведутся дискуссии о том, стоит ли просто объем в строках кода. Это как минимум явное нарушение ЯГНИ. В VS я обычно сталкиваюсь с целыми файлами кода, написанными в IDE, в которых есть ошибки, которые мне в конечном итоге нужно выяснить. Мне не нравится вычислять код, который я не писал.

Затраты на разработку.

То же самое выше. Кроме того, java хорошо известен всеми XML-файлами конфигурации, которые вам нужно написать и поддерживать, чтобы приложение подходило друг другу. Большая часть привлекательности RoR - «конфигурация по соглашению», просто чтобы этого избежать.

Эффективность.

Утверждение, что интерпретируемые или JIT-скомпилированные языки ужасно неэффективны по сравнению со скомпилированными языками, уже давно считается самоочевидным. По большему количеству причин, чем у меня есть здесь время, это предположение ставится под сомнение; например, некоторые из более новых, более быстрых движков JavaScript.

Очевидными вещами для поиска на этом сайте и в Google являются "поздняя привязка", "динамическая типизация", "JIT-компилятор".

Answer 6

Я их использую. Возможно, только потому, что я не пробовал NHibernate, но я не могу использовать LINQ, потому что я ограничен Windows 2000, которая не запускает .NET 3. Сначала они казались идеальными, но я обнаружил достаточно странные причуды о них, чтобы начать меня выключать.

Answer 7

Я все еще использую их больше, чем хотелось бы ... Они определенно лучше, чем нетипизированные наборы данных, но вы должны быть осторожны с полями типа значений, которые могут содержать значения NULL. Если у вас есть поле Int, которое может содержать нулевое значение, вы не можете попытаться получить доступ к полю, если оно имеет нулевое значение или оно сгенерирует исключение. Вы должны сначала вызвать IsMyIntFieldNull (), чтобы проверить, является ли он нулевым или нет код. Было бы лучше, если бы типизированные наборы данных поддерживали пустые поля значений для этих столбцов, но, к сожалению, они этого не делают.