Почему мы до сих пор используем DataSets в .NET?

Краткое решение для Javascript:

Array.prototype.combine=function combine(k){    
    var toCombine=this;
    var last;
    function combi(n,comb){             
        var combs=[];
        for ( var x=0,y=comb.length;x<y;x++){
            for ( var l=0,m=toCombine.length;l<m;l++){      
                combs.push(comb[x]+toCombine[l]);           
            }
        }
        if (n<k-1){
            n++;
            combi(n,combs);
        } else{last=combs;}
    }
    combi(1,toCombine);
    return last;
}
// Example:
// var toCombine=['a','b','c'];
// var results=toCombine.combine(4);
16
задан 4 revs, 2 users 100% 23 March 2009 в 22:36
поделиться

8 ответов

Я никогда не использовал DataSet правильно (сцепленный до SQL Server), но это было полезно для конкретной потребности однажды. Я нашел, что DataSet и DataView были довольно удобными и функциональными базовыми классами для реализации уровня data/BLL, пока я не мог поместить что-то действительно продуманное на месте. Существует большая функциональность назад там, что необходимо знать, если ничто иное.

6
ответ дан overslacked 24 March 2009 в 08:36
поделиться

Я думаю, что самая большая проблема с наборами данных, они в основном поощрили Вас создавать DBMS в памяти. Я люблю способ, которым Linq/entities удовлетворяют Ваши потребности данных, и они полагаются на стандартные классы наборов .NET и дженерики для работы.

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

6
ответ дан Spence 24 March 2009 в 08:36
поделиться

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

при игнорировании реляционных баз данных в целом существует все еще использование для DataSets:

  • , Если Вы пишете приложение форм, которое должно загрузить и сохранить данные в файл, можно определить введенный DataSet, затем загрузить и сохранить их с помощью класса XmlDataDocument.

  • Crystal Reports может генерировать отчеты путем чтения DataSets в оперативной памяти. Можно создать введенный DataSet только для одного конкретного отчета и использовать язык.NET для записи сложной бизнес-логики для заполнения этого DataSet. Это сохраняет Вас от реализации бизнес-логики с помощью функциональности Crystal Reports (который может быть действительно трудной задачей)

  • , можно присоединить DataGridView к DataSet с одной строкой кода для получения дрянного пользовательского интерфейса, который, тем не менее, мог бы сделать задание, в котором Вы нуждаетесь. Хороший для вещей как внутренние инструменты тестирования. (Не достаточно хороший для поставки клиенту).

2
ответ дан Andrew Shepherd 24 March 2009 в 08:36
поделиться

Я думаю, что нахожусь в одной лодке: Я очень редко использую наборы данных, и я, конечно, не утверждаю, что был экспертом по модели адаптера (я думаю" Fill", единственный метод, который я действительно использовал в производстве) - но у них действительно иногда есть некоторое использование. Например, если необходимо выполнить некоторый специальный код SQL, не может предсказать схему (и таким образом, ORM не помогает), и не хотят смешивать с IDataReader и т.д. для простого, маленького набора данных.

Кроме того (т.е. большую часть времени), я предпочитаю стандартные классы - или ORM или руководство.

2
ответ дан Marc Gravell 24 March 2009 в 08:36
поделиться

Что бы там ни было ответ является простотой. Когда 2.0 Платформы вышли, и TableAdapters были включены в процессе, стало смехотворно легко получить Ваше основное приложение типа CRUD, или даже размещенные на первой полосе данные показа, прокрутку. Просто соединитесь с Вашим разъединять, перетащить Вашу таблицу (таблицы), и структура существовала, включая внешние/основные/уникальные ключи ссылки. Потребность выполнить обновления на этих данных? Используйте мастер, укажите Ваши существующие процедуры или позвольте мастеру генерировать специальные / хранимые процедуры для Вас.

И Вы сделаны, рычаг, что до GridView и можно быстро сделать много вещей: курорт, перезапрос, редактирует несколько записей, в то время как разъединено и обновления в единственном или объемном. От этого вида удобства трудно отказаться, когда Вы работаете над проектами, которые хотят быть сделанными быстро. Плюс наличие вещей в этом собственном формате "Таблицы данных" становятся удобными для интриг XML, если, в именно это Вы нуждаетесь, так как модель DataSet использует XML под капотом для большого количества материала.

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

При наблюдении, что новый Динамический сайт/проект Услуги передачи данных создается прочь LINQ к SQL или LINQ к EF, я думаю, что поток мог бы наконец измениться на более новую модель.

9
ответ дан 30 November 2019 в 21:11
поделиться

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

1
ответ дан 30 November 2019 в 21:11
поделиться

3 причины любить наборы данных:

  • Для winforms они поддерживают привязку данных / фильтрацию, большинство orms этого не делают
  • Многие сторонние инструменты (инструменты для создания отчетов esp) имеют встроенную поддержку таблиц данных / наборы, а не для простых объектов ..
  • Во время отладки вы можете щелкнуть правой кнопкой мыши заполненную таблицу и просмотреть ее содержимое. Это настоящий экономия времени.

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

2
ответ дан 30 November 2019 в 21:11
поделиться

Я использую типизированные наборы данных для очень низкого уровня управления. Я знаю, что это не так хорошо, но попробуйте объяснить это крупным игрокам ..
Поэтому вместо того, чтобы изменить мир и ввести какой-либо инструмент oss, отличный от Microsoft (или, наконец, перейти с .net2.0 на 3.5 и использовать l2s или ef), я просто использую набор данных для хранения результатов моих запросов и легко привязываю их к сеткам , текстовые поля и поля со списком там, где это необходимо. Я считаю очень полезной возможность позже использовать что-то вроде

MyDataSet.MyDataTableRow row = // whatever
if (row.Price > 100) // do something

.

0
ответ дан 30 November 2019 в 21:11
поделиться
Другие вопросы по тегам:

Похожие вопросы: