Организация импортирующего функционала при работе с EntityFramework

@G@leON · Регистрация: 02.06.2009

Студворк — интернет-сервис помощи студентам

Доброго времени суток, дорогие гуру. Есть у меня разработанная под приложение БД, есть уже все сущности, описан Context со всякими FluentAPI... НО, еще у меня есть несколько разнородных источников данных (имею ввиду различные xls-файлики и прочее мракобесие); так вот - данные с этих источников нужно будет переодически в БД импортировать (конечно, если бы с приложением работал специалист, умеющий в написание SQL-скриптов, парится бы не пришлось, но ввиду отсутствия онного).
В целом, с какой стороны укусить я знаю, но в виду недостатка опыта разработки хочу спросить, как организовать код будет лучше. Помогите Даше решить загадку: "Есть ~~2 стула~~ 3 варианта"
1. Создать static class Importer (аля фабрика статик методов);
2. В контекстном классе импортирующие методы для экземпляра соответствующего контекста;
3. Через класс манагер, который в себе имеет экземпляр контекста, управляет операциями чтения записи; нууууу и там же сделать импорт (очевидно этот вариант звучит приятней, НО, я пока класс манагер не писал, и особо не планирую, ибо думаю что после меня никто дописывать это приложение не будет, а даже если и будет, то код открытый, а на сам EF документации хоть закопайся, зачем усложнять/упрощать людям жизнь???).

Что бы понятней было, скажем есть сущность:

C#
1
2
3
4
5
6
7
8
9
10
11
public partial class Vendor
{
  public int VendorID { get; set; }
  public string VendorName { get; set; }
  
  public DbSet<DeviceAccount> Devices { get; set; }
  
  public Vendor() {
    Devices = new DbSet<DeviceAccount>();
  }
}

Есть некоторый контекс... А еще есть сторонний источник данных с перечислением всех вендоров аппаратного обеспечения в виде пар VEN;VendorName... Алгоритм импорта примерно следующий:
1. Берем очередную строку файла.
2. Делаем: ven = new Vendor("очередная строка").
3. dbContext.Vendors.Add(ven)
4. Повторяем 1-3, пока не конец файла.
5. Если все ОКЕЙ, коммит, ну а если не окей, то роллБэк и вывалиться исключение.

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

@Usaga · 29.03.2017, 07:38

G@leON, что-то сложно всё вышеописанное переварить. Я выделил следующую проблему: есть пучок разных источников данных, из которых нужно импортировать в одну БД.

Если это так, то сложности я не вижу. Каждый источник данных прячете за абстракцией (типа ISomeDataProvider или как боженька надушу положит) с общим интерфейсом (по возможности) и выгребаете из них данные единообразным способом в виде коллекций объектов (включенных в модель данных EF).

@G@leON · 29.03.2017, 10:43 **[ТС]**

Т.е. создать класс/набор классов от абстракции, которая данные из источника данных превращает в коллекцию типизированную под нужную мне сущность и включить данную абстракцию в контекстный класс? Типо в классе унаследованном от DbContext будут переменные типов ISomeDataProvider, и когда я запускаю импорт, в контексте создается экземпляр такого провайдера, а когда импорт прошел/неПрошел - экземпляр диспозится.

@Usaga · 29.03.2017, 10:53

G@leON, нет, совсем не так.

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

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

Но такой вариант возможен, если все поставщики могут возвращать один тип объекта. Если нет, то всё равно источники данных лучше было бы завернуть в провайдеры...

Новые блоги и статьи Все статьи Все блоги /
делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью	SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .
Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .	SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .

@Usaga 14303 / 9388 / 1354 Регистрация: 21.01.2016 Сообщений: 35,398
	29.03.2017, 07:38
	G@leON, что-то сложно всё вышеописанное переварить. Я выделил следующую проблему: есть пучок разных источников данных, из которых нужно импортировать в одну БД. Если это так, то сложности я не вижу. Каждый источник данных прячете за абстракцией (типа ISomeDataProvider или как боженька надушу положит) с общим интерфейсом (по возможности) и выгребаете из них данные единообразным способом в виде коллекций объектов (включенных в модель данных EF). 1

@G@leON 6 / 6 / 2 Регистрация: 02.06.2009 Сообщений: 99
	29.03.2017, 10:43 [ТС]
	Т.е. создать класс/набор классов от абстракции, которая данные из источника данных превращает в коллекцию типизированную под нужную мне сущность и включить данную абстракцию в контекстный класс? Типо в классе унаследованном от DbContext будут переменные типов ISomeDataProvider, и когда я запускаю импорт, в контексте создается экземпляр такого провайдера, а когда импорт прошел/неПрошел - экземпляр диспозится. 0

@Usaga 14303 / 9388 / 1354 Регистрация: 21.01.2016 Сообщений: 35,398
	29.03.2017, 10:53
	G@leON, нет, совсем не так. Для каждого источника данных (кроме БД), создаёте свой класс-поставщик данных. Очень желательно чтобы эти поставщики имели общий интерфейс (вам же проще и удобнее с этим работать), чтобы можно было единообразно с данными поставщиками работать. Поставщики должны возвращать коллекции объектов, с которыми сможет работать ваш контекст. Т.е. есть коллекция поставщиков данных, некоторый алгоритм их перебирает в цикле, и полученные данные отправляет в контекст на сохранение. Но такой вариант возможен, если все поставщики могут возвращать один тип объекта. Если нет, то всё равно источники данных лучше было бы завернуть в провайдеры... 0