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

Question

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

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

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

-Эрик Сиппл

Answer 1

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

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

Answer 2

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

Answer 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.

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Я использую ObservableCollection

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

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

Answer 8

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

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

EDIT:

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

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

Answer 9

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

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

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

Answer 10

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

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