С#: что еще вы используете помимо DataSet

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

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

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

-Eric Sipple

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

Я большой поклонник 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.

Ответ 6

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

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

Я использую ObservableCollection

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

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

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

Ответ 11

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

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

EDIT:

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

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

Ответ 12

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

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

Ответ 13

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