C#: Что еще вы используете, кроме DataSet


20

Я обнаружил, что я все больше не удовлетворен парадигмой DataSet/DataTable/DataRow в .Net, главным образом потому, что это часто на несколько шагов сложнее, чем то, что я действительно хочу делать. В случаях, когда я привязываюсь к элементам управления, DataSets в порядке. Но в других случаях, кажется, существует много умственных накладных расходов.

Я немного поиграл с SqlDataReader, и это кажется хорошим для простых прогулок через выделение, но я чувствую, что могут быть некоторые другие модели, скрывающиеся в .Net, которые полезны, чтобы узнать больше. Я чувствую, что вся помощь, которую я нахожу на этом, просто использует DataSet по умолчанию. Возможно, это и DataReader действительно лучшие варианты.

Я не ищу лучший/худший провал, просто любопытно, какие у меня есть варианты и какие у вас были впечатления. Благодаря!

-Эрик Сиппл

20

С .NET 3.5 вышел, я только использовал LINQ. Это действительно так хорошо; Я не вижу никакой причины использовать какие-либо из этих старых костылей.

Так же, как LINQ, я думаю, что любая система ORM позволит вам покончить с этим dreck.

  0

Вы имеете в виду LINQ To SQL (aka L2S)? 11 дек. 092009-12-11 15:50:34

  0

Очевидно, что мы говорим о доступе к базе данных. Хотя LINQ для всего остального так же хорош. 16 дек. 092009-12-16 03:21:41


4

Мы отошли от наборов данных и построили наши собственные объекты ORM свободно на основе CSLA. Вы можете выполнить одну и ту же работу с помощью DataSet или LINQ или ORM, но повторное использование этого (мы нашли) намного проще. «Меньший код делает более счастливым».


1

Я использую их широко, но я не использую ни одну из «расширенных» функций, которые Microsoft действительно толкает, когда среда впервые появилась. Я просто использую их как Списки Hashtables, которые я считаю совершенно полезными.

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

Конечно, я один из странных, которые на самом деле предпочитают DataRow экземпляру объекта сущности.


1

Pre linq Я использовал DataReader для заполнения списка моих собственных пользовательских объектов домена, но post linq Я использовал L2S для заполнения объектов L2S или L2S для заполнения объектов домена.

Как только я получу немного времени для расследования, я подозреваю, что объекты Entity Framework станут моим новым любимым решением!


3

Я был сыт по горло данными DataSets в .Net 1.1, по крайней мере, они оптимизировали его, чтобы он не замедлялся как экспоненциально для больших множеств.

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

SqlDataReader был хорош, но я использовал для обертывания его в IEnumerable<T>, где T было некоторым типизированным представлением моей строки данных.

Linq - это гораздо лучшая замена, на мой взгляд.


0

Я просто создаю свои бизнес-объекты с нуля и почти никогда не использую DataTable, и особенно не DataSet, за исключением того, что изначально заполняют бизнес-объекты. Преимущества для создания собственных - это тестируемость, безопасность типов и intellisense, расширяемость (попробуйте добавить к DataSet) и читаемость (если вам не нравится читать такие вещи, как Convert.ToDecimal (dt.Rows [i] ["blah"]. ToString())).

Если бы я был умнее, я бы также использовал ORM и стороннюю структуру DI, но только пока не ощутил необходимости в них. Я делаю много проектов меньшего размера или дополнений к более крупным проектам.


2

DataSets отлично подходят для демонстрации.

Я не знаю, что с ним делать, если вы заставили меня использовать его.

Я использую ObservableCollection

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

DataReaders бывают быстрыми, так как они представляют собой только прямой поток результирующего набора.


1

Выбор современного, стабильного и активно поддерживаемого инструмента ORM должен быть, пожалуй, самым большим повышением производительности практически для любого проекта среднего размера и сложности. Если вы заключаете, что абсолютно вам абсолютно необходимо писать свои собственные DAL и ORM, вы, вероятно, ошибаетесь (или используете самую неясную базу данных в мире).

Если вы делаете необработанные наборы данных и строки, а что нет, потратьте день на попытку ORM, и вы будете поражены тем, насколько продуктивнее вы можете без труда переносить столбцы на поля или все время заполняя командные объекты Sql и все остальные прыжки, которые мы все когда-то проходили.

Я обожаю меня подзвуковым, хотя для проектов меньшего масштаба вместе с демонстрационными/прототипами я нахожу Linq to Sql довольно чертовски полезными. Хотя я ненавижу EF. : P


3

Я использую шаблон Data Transfer Objects (как я полагаю, из мира Java) с помощью SqDataReader для заполнения коллекций DTO из уровня данных для использования в других слоях приложения. сами DTO - очень легкие и простые классы, состоящие из свойств с gets/sets. Они могут быть легко сериализованы/десериализованы и использованы для привязки данных, что делает их очень хорошо подходящими для большинства моих потребностей в развитии.


-1

Я НИКОГДА не использую наборы данных. Это большие тяжеловесные объекты, которые можно использовать (как кто-то указал здесь) на «demoware». Здесь представлено множество отличных альтернатив.

  0

"Тяжелые предметы"? Действительно ли этот термин имеет какой-либо смысл? 19 ноя. 092009-11-19 20:07:22

  0

Да, есть существенное значение. Сериализуйте набор данных с помощью всего нескольких строк в файле XML и посмотрите, насколько он большой. Затем сделайте простой объект передачи данных (ответ Джесси). Просто определите простой класс с членами для каждого столбца, а затем класс List <DTO>. Сериализуйте это в файле XML - и взгляните на разницу. 25 ноя. 092009-11-25 17:02:16

+1

Если вы действительно сериализуете DataSets, а затем передаете их по проводу или что-то в этом роде, и есть настоящая проблема с производительностью, это одно.Но я видел, что «DataSet bloat» используется в качестве оправдания для создания отвратительного, строкового литерала, который использует DataReaders везде в слишком многих магазинах, в которых я работал. 11 дек. 092009-12-11 15:32:01

  0

Конечно, замена одной плохой реализации другим - это отвратительное решение - но мне еще предстоит увидеть решение с использованием набора данных, которое не может быть реализовано лучше, чем более эффективно, без него. Наборы данных полезны для «DEMOware» и удержания от pre -.NET ADO 11 дек. 092009-12-11 16:10:05

  0

Теперь, похоже, это заставляет меня думать, что вы не очень хорошо работали с ADO.NET DataSets и, возможно, просто не знаете о них вообще. ADO.NET DataSets отключены; они являются контейнерами для данных. Они применяют такие вещи, как отношения к базе данных и недействительность, поэтому у них так много методов и свойств, что люди называют «раздуванием». Я могу понять, почему люди не предпочитают их в качестве стиля, но они являются надежной альтернативой для тех, кто не против более ориентированного на базу данных (а не ориентированного на объектно-ориентированную модель) стиля. 14 дек. 092009-12-14 15:53:19


3

Я большой фанат SubSonic. Хорошо написанный пакетный/CMD-файл может генерировать целую объектную модель для вашей базы данных за считанные минуты; вы можете скомпилировать его в свою собственную DLL и использовать его по мере необходимости. Замечательная модель, замечательный инструмент. Сайт делает его похожим на сделку ASP.NET, но, как правило, он отлично работает где угодно, если вы не пытаетесь использовать его интерфейс (который я умеренно разочарован) или его инструменты автоматического генерации на уровне приложений ,

Для записи, вот версия команды я использую для работы с ним (так что вам не придется бороться с ним очень трудно изначально):

sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true 

Это делает это каждый раз. Затем создайте DLL из этого каталога - это часть проекта NAnt, выпущенного CruiseControl.NET, и мы уходим. Я использую это в WinForms, ASP.NET, даже некоторые утилиты командной строки. Это создает наименьшее количество зависимостей и большую «переносимость» (между связанными проектами, EG).

Примечание

выше теперь более чем год назад. В то время как я все еще испытываю большую любовь к моему SubSonic, я перешел к LINQ-to-SQL, когда у меня есть роскошь работы в .NET 3.5. В .NET 2.0 я все еще использую SubSonic. Поэтому мой новый официальный совет зависит от платформы. В случае .NET 3+ идите с принятым ответом. В случае .NET 2.0 перейдите в SubSonic.


1

Я использовал типизированные DataSets для нескольких проектов. Они хорошо моделируют базу данных, применяют ограничения на стороне клиента и в целом представляют собой надежную технологию доступа к данным, особенно с изменениями в .NET 2.0 с помощью TableAdapters.

Напечатанные DataSets получают плохой рэп от людей, которые любят использовать эмоциональные слова, такие как «раздутые», чтобы описать их. Я дам, что мне нравится использовать хороший O/R mapper больше, чем использование DataSets; он просто «чувствует» лучше использовать объекты и коллекции вместо типизированных DataTables, DataRows и т. д. Но я обнаружил, что если по какой-либо причине вы не можете или не хотите использовать картографию O/R, набрав DataSets - хороший надежный выбор, который достаточно прост в использовании, и вы получите 90% преимуществ карты O/R.

EDIT:

Некоторые предполагают, что здесь DataReaders являются "быстрый" альтернатива. Но если вы используете Reflector, чтобы посмотреть на внутренности DataAdapter (какие DataTables заполнены), вы увидите, что он использует ... DataReader. Типированные данные могут имеют больший объем памяти, чем другие параметры, но я еще не видел приложение, где это имеет ощутимое различие.

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

  0

Я не уверен, что ваш комментарий действителен - DataSet заполняется с помощью DataAdaptor, который использует DataReader, но когда доступны данные? Если вам нужно подождать, пока чтение всех строк не будет завершено, конечно, это должно быть медленнее. 02 июн. 102010-06-02 06:24:34

  0

Это зависит от того, что вы делаете с данными. Возможно, вы обрабатываете большой набор данных по строкам; возможно, вы работаете в полном комплекте и ничего не можете сделать, пока не получите все это. Возможно, вы получаете эквивалент одной строки, и не имеет значения, что вы используете. * Всегда * отказ от DataSets является преждевременной оптимизацией. И если вам нужно редактировать и сохранять данные, DataSets намного проще работать, чем DataReaders и временные объекты. Чтобы избежать их, вы должны запутать свой код без причины. 05 июн. 102010-06-05 16:58:52


2

Я использовал типизированные и нетипизированные DataSets, DataViewManagers, DataViews, DataTables, DataRows, DataRowViews и практически все, что вы можете сделать со стеком, поскольку оно впервые появилось в нескольких корпоративных проектах. Мне потребовалось некоторое время, чтобы привыкнуть к тому, как разрешить это. Я написал пользовательские компоненты, которые используют стек, поскольку ADO.NETdid не совсем дает мне то, что мне действительно нужно. Один из таких компонентов сравнивает DataSets, а затем обновляет бэкэнд-магазины. Я действительно знаю, как все эти элементы работают хорошо, и те, кто видел то, что я сделал, очень впечатлены тем, что мне удалось выйти за пределы, чувствуя, что это полезно только для демонстрационного использования.

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

Я искал сегодня для замены ADO.NET, и я не вижу ничего, что я должен серьезно попытаться заменить тем, что я сейчас использую.