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

Question

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

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

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

-Эрик Сиппл

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

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

Я использую ObservableCollection

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

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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

Answer 11

Я большой фанат 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.

Answer 12

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

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

EDIT:

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

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

Answer 13

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

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

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