DataSet или Entity Data Model

Question

Пожалуйста, извините за вопрос noob, поскольку я новичок в интеграции данных с моими приложениями.Я пытался найти ответы в сети, но пока нет.

У меня есть приложение, которое я разрабатываю на C # на VS2010, для которого требуются данные из базы данных.Я пытаюсь выяснить, является ли это DataSet или Entity Data Model, которую мне нужно использовать при настройке источника данных.Насколько я понимаю, именно EDM позволил мне обрабатывать таблицы / поля в базе данных как объекты, но почему-то похоже, что я могу сделать это и с DataSet.

Некоторые источники объясняют, что DataSet создаеткэшированная копия базы данных, которой затем можно манипулировать.

По сути, мой вопрос заключается в том, что я должен использовать и каковы (не) преимущества одного перед другим.

Answer 1

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

1. На самом простом уровне используйте ADO.NET, чтобы открыть соединение с БД., создайте команду и выполните ее.Если вы ожидаете результатов назад (т.е. SELECT ...), вы можете вызвать команду ExecuteReader (...) .Работа таким образом приводит к очень быстрому выполнению и минимуму накладных расходов, но вы должны делать больше тяжелой работы.Если ваше приложение простое, возможно, это хороший путь.Если ваше приложение является или может быть более сложным, вы можете рассмотреть другие варианты ...
2. ADO.NET DataSets - разумный механизм ввода-вывода БД, особенно для чтения данных из БД.Однако при обновлении БД они могут быть немного громоздкими.
3. Вы можете использовать объектно-реляционный маппер (ORM), например, nHibernate или Entity Framework, но, честно говоря, это часто приводит к увеличению кривой обучениязначительно, пока вы выясняете, как соединить движущиеся части и заставить их хорошо работать вместе.
4. Вы могли бы также рассмотреть новый вариант Entity Framework под названием Code First (CF): это позволяет вам в значительной степени проектировать своиcode и CF сгенерируют ваш EDM и будут выполнять большинство операций с БД, необходимых для построения вашей системы. Скотт Хансельман написал хорошее введение в EF CF .

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

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

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

Answer 2

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

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

По сути, Entity Data Model - более новая технология. Если вы не знакомы с Dataset, возможно, сейчас не время его использовать.

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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