Организация импортирующего функционала при работе с 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, нет, совсем не так.

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

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

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

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@Usaga 14321 / 9411 / 1356 Регистрация: 21.01.2016 Сообщений: 35,481
	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 14321 / 9411 / 1356 Регистрация: 21.01.2016 Сообщений: 35,481
	29.03.2017, 10:53
	G@leON, нет, совсем не так. Для каждого источника данных (кроме БД), создаёте свой класс-поставщик данных. Очень желательно чтобы эти поставщики имели общий интерфейс (вам же проще и удобнее с этим работать), чтобы можно было единообразно с данными поставщиками работать. Поставщики должны возвращать коллекции объектов, с которыми сможет работать ваш контекст. Т.е. есть коллекция поставщиков данных, некоторый алгоритм их перебирает в цикле, и полученные данные отправляет в контекст на сохранение. Но такой вариант возможен, если все поставщики могут возвращать один тип объекта. Если нет, то всё равно источники данных лучше было бы завернуть в провайдеры... 0

Опции темы