Почему я хочу держаться подальше от DataSets, и каковы альтернативы?

Question

Я нашел интересное обсуждение здесь:

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=43315&discussionID=12708606&goback=.anh_43315

Цитата:

DataSets - это непрофессиональные решения для кодирования вашего слоя данных ... Прекратите использовать их и научитесь кодировать! :)

Каково ваше мнение о DataSets, а не о том, чтобы просто заглушить пользовательские классы и работать с ними? Какие есть другие альтернативы?

Answer 1

Помимо снобизма, DataSets может быть полезен в приложениях с относительно простой бизнес-логикой, где разработчик имеет некоторый контроль над схемой базы данных, так что таблицы данных соответствуют бизнес-объектам 1: 1 (которые в этом случае обычно состоят из DataRow ).

Мартин Фаулер очень четко обсуждает это в «Шаблонах архитектуры корпоративных приложений» ( Amazon link ). Наборы данных ( Табличный модуль в номенклатуре Фаулера) хорошо соответствуют сценарию транзакции , тогда как Модель предметной области требует более четко определенных классов и сопоставления с базой данных (поскольку корреляция 1: 1 между бизнес-объектами и таблицами в этой ситуации обычно недостижима).

DataSets / Table Module имеет множество ограничений, но они имеют преимущества в простоте, особенно если вы работаете в .NET.

Прагматичный программист оценит требования конкретного приложения и применяет шаблоны и технологии, которые подходят лучше всего, даже если они не самые сексуальные. Для простых сценариев с простым отображением 1: 1 на реляционные данные наборы данных не нужны. Однако часто они так и делают, и любой программист, который полагается исключительно на них, сталкивается с проблемами в более сложных сценариях.

Answer 2

Существует много причин использовать OR / Mapper.

Главным образом:

• Он генерирует безопасные типы во время компиляции для ваших таблиц
• Как правило, существует многоуровневая область, в которую можно добавить соответствующие функции бизнес-логики и представления.
• Упрощает доступ к данным (сохранение / загрузка, глубокое сохранение и т. Д.)
• Упрощенный / лучший процесс загрузки объектов, связанных с FK (в зависимости от каркаса)

Я мог бы продолжить.

Я предлагаю вам внимательно изучить ваше ИЛИ / Mapper. Лично я практически влюблен в LLBLGen Pro (но это стоит денег). Другим нравятся другие, я считаю их немного сумасшедшими, но каждому свое. Что вы действительно хотите от OR / Mapper:

• Гибкость
• Скорость
• Многослойное поколение
• Поддержка в рамках (CF и т. Д., Если применимо)

Так что пересмотрите сами и примите решение.

Answer 3

Один большой недостаток заключается в том, что наборы данных являются структурами данных в памяти, что означает, что объем потребляемой памяти является линейным по отношению к количеству возвращаемых вами записей (то есть O (n) сложность пространства). В приложении на стороне сервера это убивает масштабируемость.

Если вы определяете пользовательский класс T, то возвращение IEnumerable из уровня доступа к данным позволяет вам эффективно передавать данные из вашего источника данных (например, поставщика Linq to Sql IQueryable) со сложностью O (1).

Примечание: та же проблема возникает, если вы возвращаете List или Collection из уровня доступа к данным, поскольку они также являются структурами в памяти. Я видел, что многие люди делают это во имя элегантности без учета масштабируемости.