DataSet или модель данных сущности

Ответ 1

У вас есть несколько вариантов, открытых для вас, когда дело доходит до хранения и извлечения данных в/из базы данных:

• На самом простом уровне используйте ADO.NET, чтобы открыть соединение с БД, создать команду и выполнить ее. Если вы ожидаете результатов назад (т.е. SELECT...), вы можете вызвать команду ExecuteReader (...). Работа таким образом приводит к очень быстрому исполнению и минимуму накладных расходов, но вы должны делать больше тяжелой работы. Если ваше приложение простое, это, вероятно, хороший способ. Если ваше приложение или, вероятно, будет более сложным, вы можете рассмотреть другие варианты...
• ADO.NET DataSets - это разумный механизм ввода-вывода DB, особенно для чтения данных из БД. Тем не менее, они могут быть немного громоздкими при попытке обновить БД.
• Вы можете использовать Object-Relational Mapper (ORM), например nHibernate или Entity Framework, но, откровенно говоря, это часто приводит к тому, что ваша кривая обучения значительно возрастает, когда вы выясняете, как подключить движущиеся части и заставить их работать вместе.
• Вы также можете рассмотреть новый вариант Entity Framework под названием Code First (CF): это позволяет вам в значительной степени спроектировать ваш код, а CF сгенерирует ваш EDM и обрабатывает большинство операций с БД, необходимых для создания вашей системы, Скотт Гензельман написал хорошее введение в EF CF.

Используя практически каждый API БД и ORM в Windows за последние 20 лет, я в восторге от того, как CF формируется! EF 4.3, который был отправлен всего пару недель назад, включает некоторые ключевые новые улучшения в CF, включая миграцию, которые позволяют обрабатывать изменения в вашей схеме БД по мере ее развития. Я создал 3-4 системы с использованием EF CF за последние пару месяцев, и я очень счастлив - это мой любимый механизм IO реляционной базы данных в настоящее время.

Если вы действительно хотите попасть в EF CF, Я настоятельно рекомендую книгу Джулии Лерман EF CF - это короткая, красиво написанная, очень полезная руководство, которое должно пройти не более одного дня или двух, чтобы работать через основные разделы.

Надеюсь, что это поможет.

Ответ 2

Если вы добавите источник данных LocalDB в свой проект (потому что вам нужен небольшой локальный файл базы данных), то при появлении мастера настройки источника данных он явно спрашивает вас, хотите ли вы использовать модель базы данных Data Data или модель данных сущностей, Это ситуация, с которой вы столкнулись? Это была проблема, с которой я столкнулся, что привело меня к этой записи.

Нет никаких сомнений в том, что для приложения корпоративного класса или веб-сайта вы хотели бы исследовать ADO.NET или ORM, но это не помогает ответить на этот вопрос, что связано с различиями между выбор Dataset vs Entity Data Model в мастере.

По существу, модель данных сущностей - это новейшая технология. Если вы не знакомы с Dataset, то, вероятно, не время для его использования.

Ответ 3

Если вы спрашиваете, какие плюсы и минусы для ADO.NET(DataSet) и EntityFramework (Entity Data Model), то есть обсуждение, которое может помочь в ADO.NET Entity Framework или ADO.NET

EF заставит вас работать довольно быстро, но в моем (очень ограниченном) опыте это было болью для поддержания.

Что это значит, что это ваши два варианта? Вам доступно гораздо больше, включая множество ORM.

Ответ 4

Если ваше приложение поддерживает бизнес-приложение, а запросы довольно сложны. В таком случае хранимые процедуры сохраняют много времени и намного проще в обслуживании, и они лучше работают с ADO.NET. Почти во всех сценариях я бы предложил использовать хранимые процедуры и ADO.NET. Переместите как можно больше бизнес-правил и логики в хранимые процедуры, так как вы... намного проще поддерживать этот путь.

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

Вы можете (должны) использовать бизнес-объекты в приложении для бизнес-логических процессов.

Давайте рассмотрим простой пример того, где вы сохраняете контакт (имя, телефон, адрес электронной почты, адрес и т.д.), а затем извлекаете список контактов, добавленных сегодня... Я предлагаю вам сделать это следующим образом:

1) Добавление контакта - Клиент (Интернет или другой) собирает данные → данные сохраняются в бизнес-объекте Contact → validate Contact object → Уровень репозитория вызовов для сохранения объекта Contact (добавление слоя репозитория полезный, но не необходимый для сохранения абстрактного уровня данных от клиента) → Репозиторий вызывает слой данных для сохранения контактного объекта (здесь может быть сделан простой вызов ADO.NET с использованием объекта Command, чтобы вызвать хранимую процедуру для сохранить контакт в базе данных). В этом случае не использовался набор данных.

2) Извлечение списка контактов - Клиент вызывает слой репозитория для получения списка контактов → уровень репозитория вызывает слой данных для извлечения данных → здесь список данных извлекается как набор данных (datatable ) → вернуть данные обратно к клиенту и позволить клиенту считывать данные непосредственно из данных при рендеринге данных. Даже один контакт можно получить в виде набора данных.

P.S: ORM почти всегда является излишним. Это почти всегда используется, потому что некоторым разработчикам нравится сохранять все объектно-ориентированные... поэтому добавляется дополнительный слой, хотя он ничего не делает полезными (IMHO).

Ответ 5

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