EF6 + ...
Чем больше Я смотрю на биллины поделки - тем меньше мне хочется работать...
Возможно, однако, что это от незнания инструмента.
Задачка:
- есть неприятная база данных. Неприятность ее очень разная - от "не правильных имен" полей и таблиц, до отсутствия и невозможности нарисовать реляции.
- есть необходимость оперировать объектами, более сложными, чем имеющиеся в базе примитивы. Такими как Заказ, с его составляющими и ценами.
- структура этих сложных объектов до конца не определена. Т.е. на сегодня Я знаю только ту часть структуры объектов, с которой доводилось работать.
- предстоит миграция на новую базу. База - совершенно другая по структуре и имеющиеся наработки никак не подойдут.
Вопросик 1 - можно ли используя ЕФ6 построить интересующую меня модель и связать ее с имеющейся базой?
Повторюсь - прямого отображения модели на базу не будет - нужно что-то большее чем ОРМ.
Вопросик 2 - если не ЕФ6, то чем можно пользоваться?
Типичная проблема: в Заказе есть юнит-сборка из двух панелей. Внешняя панель - двух-... иногда - трех- слойная склейка, внутренняя - однослойное стекло. Информация об однослойном стекле хранится в 3-4 таблицах, информация об сборке - в десятке других. При этом сами таблицы и в первом и во втором случаях - не фиксированные - зависят от того какое именно используется стекло и как его нужно обрабатывать.
Чем это можно покрыть?
-----
Идея мне очень нравится. И даже планирую ею воспользоваться. Правда - черeз год. Вот этот год мне и нужно имитировать решение поставленной задачи.
Вопрос только в том - Как это делать?
С dapper кто-нибудь работал? Как он в работе? Интересует - с ПостгреСКЛ
Попалась еще одна биллина фича...
Задачка примитивная - найти все файлы поименованные "devenv.exe.config" на системном диске и содержащие текст "Ngpsql"
Используется поиск Студии, Поиск подтверждает задачу:
Find all "Ngpsql", Subfolders, Find Results 1, "C:\", "devenv.exe.config"
Фича:
проверены ВСЕ файлы на наличие текста "Ngpsql"...
найдена куча файлов которые содержат искомый текст...
файлы - "devenv.exe.config" - с указанным текстом - НЕ НАЙДЕНЫ
Хотя я точно знаю что пара таких есть...
Мать-мать-мать...
Билиииинннн...
Доковырялся - пришлось снести все три студии... полностью.
Переинсталлировал версию 2015 Коммунити.
Мать-мать-мать...
Полная деинсталяция, полная инсталяция, отказ от старой конфигурации...
И, бляяяя... все старые адд-оны на месте...
Мать-мать-мать...
В добавок еще и vbcscompiler.exe - отваливается несколько раз в процессе билда...
Мать-мать-мать...
Похоже завтра надо будет чистить комп...
Очередной бииилииинннн....
Решил, что надо попробовать починить "снизу" - деинстальнул Студию и запустил мелкомягкий фихер для установленного .Нет фреймворка...
Фихер - свеженький - прямо с мелкомягкого сайта...
И... нефига - не могЕт он починить инсталляцию фреймворка... а вот найти все логи и отослать их мелкомягким... без разрешения - это на раз-два...
Задачка:
- есть неприятная база данных. Неприятность ее очень разная - от "не правильных имен" полей и таблиц, до отсутствия и невозможности нарисовать реляции.
- есть необходимость оперировать объектами, более сложными, чем имеющиеся в базе примитивы. Такими как Заказ, с его составляющими и ценами.
- структура этих сложных объектов до конца не определена. Т.е. на сегодня Я знаю только ту часть структуры объектов, с которой доводилось работать.
- предстоит миграция на новую базу. База - совершенно другая по структуре и имеющиеся наработки никак не подойдут.
Вопросик 1 - можно ли используя ЕФ6 построить интересующую меня модель и связать ее с имеющейся базой?
Повторюсь - прямого отображения модели на базу не будет - нужно что-то большее чем ОРМ.
Вопросик 2 - если не ЕФ6, то чем можно пользоваться?
Типичная проблема: в Заказе есть юнит-сборка из двух панелей. Внешняя панель - двух-... иногда - трех- слойная склейка, внутренняя - однослойное стекло. Информация об однослойном стекле хранится в 3-4 таблицах, информация об сборке - в десятке других. При этом сами таблицы и в первом и во втором случаях - не фиксированные - зависят от того какое именно используется стекло и как его нужно обрабатывать.
Чем это можно покрыть?
Т. е. вам нужно ввести свой слой (application layer). Вероятно, что придётся развить этот слой до полноценного репозитория. Т. е. этот новый слой будет получать из другого слоя или из внешнего мира объект, соответствующий вашей бизнес-логике (например, ваша "внешняя панель"), и как-то раскидывать его по таблицам вашей старой базы данных. Также и с получением данных из этой БД - чтобы собрать объект вашей бизнес-логики, вам нужно будет сделать комплексный запрос к вашей старой БД.
Обычно так и делают - если объект взаимодействия представляет из себя (частично) чёрный ящик, и нет возможности его заменить (переписать), то городят слои всяких "конвертеров", "адаптеров" и прочих костылей.
Лучше, конечно, переработать старую БД под новую - с реляциями и более соответствующую вашей бизнес-логике, чтобы не надо было заниматься сложными преобразованиями объектов между слоями.
Если в старой БД нет реляций (хотя, это странно - скорее всего, эти реляции захардкодены где-нибудь в коде, т. е. другие программы знают, как относятся между собой сущности этой БД), то в новой вы их придумаете сами. Естественно, создавая реляции, нужно советоваться со специалистами-предметниками в вашей области, если они есть, чтобы не создавать нелогичных для вашей предметной области отношений между сущностями.
А почему претензии именно к EF6? Думаете, Hibernate в этом сильно лучше поможет?
Модели сущностей для вашего слоя абстракции вообще к EF можно не привязывать (особенно, если вы по этим моделям потом не собираетесь генерить новую БД - EF Code First (EFCF)), если речь идёт о данных. Но в функциональной части вашего репозитория вы будете сохранять/запрашивать/изменять/удалять модели вашего слоя через обращение к вашей старой БД (напрямую или через тот же слой ORM, сгенеренный EF). Но если в будущем всё же планируете новую БД, основанную на ваших сущностях, то лучше в этом слое абстракции всё же применить подход EFCF.
В последнем случае я бы сделал так (но у меня мало опыта, поэтому не гарантирую удобства и прочего - проверяйте сами). Сгенерил бы автоматически ORM для старой БД. Написал бы модель (соответствующую вашей новой бизнес-логике) для новой БД с помощью EFCF. Создал бы отдельный класс-репозиторий (или адпатер, или конвертер - неважно, как назвать), который бы содержал только функциональную часть - т. е. только методы по удалению, добавлению, чтению, изменению сущностей. Сами эти методы работали бы с двумя ORM - сгенеренной для старой БД и написанной вами EFCF для новой. Как только старая БД вам не нужна (все сущности перевели в новую или просто выкинули её), то и сам репозиторий больше не понадобится, а новая модель (EFCF) у вас остаётся.
Могу ещё скинуть банальных ссылок для изучения EF.
https://docs.microsoft.com/en-us/ef/ef6/
http://www.entityframeworktutorial.net/
В некоторых местах второй источник более подробно объясняет, чем даже
сама Майкрософт в своём МСДНе. У EFCF есть преимущества и недостатки. Преимущества вижу в том, что легко создать тестовую БД по скрипту. Если вы раньше не создавали БД с помощью SQL, а только в визуальном редакторе таблиц, то оцените это, т. е. переделать с нуля БД в редакторе таблиц - это огромная работа. По скриптам же генерится всё куда быстрее. EFCF - это скрипты на C#, который более знаком программисту на C#, чем SQL, но и там куча своих нюансов. Есть вещи, что быстрее и проще сделать в визуальном редакторе. Вобщем, шишки набить придётся.