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

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

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

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

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

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

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

На мой взгляд, Linq — гораздо лучшая замена.

Я использовал шаблон Объекты передачи данных (первоначально из мира Java, я полагаю) , с SqDataReader для заполнения коллекций DTO из уровня данных для использования на других уровнях приложения. Сами DTO — это очень легкие и простые классы, состоящие из свойств с get/set. Их можно легко сериализовать/десериализовать и использовать для привязки данных, что делает их вполне подходящими для большинства моих потребностей в разработке.

Я большой поклонник 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 и даже в некоторых утилитах командной строки. Это создает наименьшее количество зависимостей и наибольшую «переносимость» (между связанными проектами, например).

Примечание

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

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

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

Я использую ObservableCollection

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЗМЕНИТЬ:

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

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

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

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

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