C#: Что Еще Вы Используете, Кроме Набора Данных

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

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

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

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

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

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

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

Я использовал шаблон объектов передачи данных (первоначально из мира Java, я полагаю) с SqDataReader для заполнения коллекций DTOs из слоя данных для использования в других слоях приложения. DTOs сами по себе очень легкие и простые классы, состоящие из свойств с gets/sets. они могут быть легко serialized/deserialized, и использоваться для привязки данных, что делает их довольно хорошо подходящими для большинства моих потребностей в разработке.

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

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

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

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

Примечание

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

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

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

Я использую ObservableCollection

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

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

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

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

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

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

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

EDIT:

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

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

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

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

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

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

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

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

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

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

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

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

Я никогда не использую наборы данных. Они являются большими тяжеловесными объектами, которые можно использовать только (как кто-то указал здесь) для "demoware". Есть много отличных альтернатив, показанных здесь.