Мапинг ef-core и наследная база

Есть древняя база данных. База рабочая и пока ещё даже развивается. Структура продумана не очень хорошо.

И есть сервис, в рамках которого описаны структуры данных, которые частично мапятся на таблицы БД по сложным правилам (и для чтения, и для записи). Например, в поле базы данных может храниться форматированная строка, представляющая из себя массив пар значений, или даже JSON, который при заборе из базы нужно получить не в виде строки, а в виде вложенной коллекции/словаря распарсенных объектов. Например, в самом простом случае, это будет что-то типа: "1;2;3;4;5;6" => List<int>.

Вопрос - есть ли смысл пытаться прописать весь этот сложный мапинг в EF-контексте через fluent-API и самописные конвертеры, или же разумнее будет автоматически создать контекст по базе, а мапинг между ним и объектами сервиса реализовывать вручную в методах репозиториев?

0

Но сначала, хочется убедиться что настроенно именно так. SomeData - Entity в БД, RawData и ProcResult - навигационные поля ведущие на реальные данные. Если нет, то где ключи и как вообще должно были данные загрузиться. Если SomeData не БД сущность, то вообще не понятно от чего сыр бор. Заполняй, выгружай. Всё равно оно на что-то должно проецироваться.

Сообщение от kotelok Есть некая сущность, в которой описана БЛ и у которой состояние закрыто приватными сеттерами и набором методов для изменения состояния в рамках бизнес-правил. Вопрос - как восстановить эту сущность (в данном случае из БД)? Один из вариантов решения - описать поверх сущности EF-правила (через fluent-API) с использованием возможности EF восстанавливать состояние приватных полей.

Если это сущность в БД то не понятно какими приватными сеттерами оно там закрыто. Можно поменять эти данные из другими путями. Если это сущность в БД то оно должно "затянуться" по обычному сценарию - например через навигационное поле. И если это специальная сущность, то "открытие" данных из неё будет отдано на логику этого класса.
Если это калькулируемое поле, то зачем тут ЕФ.

Или ситуация немного не такая или обычно задача решалась вот так:

1. Выборка вытаскивает SomeData. У него и будет поле RawData.
2. Вызывается метод Fill/Calculate() который делает какие-то действия, сбор даных или ещё что-то.
3. Конечные данные сохраняются в ProcResult
4. Сущность сохраняем. ЕФ ефтоматом сохраняет и данные и результат (в другой таблице, а здесь у нас ключ на него).

Сообщение от kotelok 1. Есть какая-то DTO, в которую из базы получены 'RawData' и 'ProcResult'. 2. Как из них воссоздать сущность 'Some'?

Сообщение от kotelok Да, есть экземпляр, изначально инициализированный 'RawData'. Потом над ним выполняется процесс обработки и результаты помещаются в 'ProcResult'. И далее этот экземпляр нужно сохранить (RawData + ProcResult), а потом восстановить в этом состоянии.

Нельзя восстановить то чего не было. Или есть сущность SomeData со связями на RawData и ProcResult или это генерация новой сущности на основании входящих данных.

Или хочется увидеть хороший пример и ТЗ.

1

kotelok, вроде бы EF Core может в приватные поля и свойства. Но должен быть конструктор без параметров.

Добавлено через 3 минуты

Сообщение от HF не понятно от чего сыр бор

От того, что ТС не видит границы между хранилищем и бизнес-логикой. Обычная фигня, когда в руки берут ORM типа EF...

1

Сообщение от Usaga От того, что ТС не видит границы между хранилищем и бизнес-логикой. Обычная фигня, когда в руки берут ORM типа EF...

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

Когда я сталкиваюсь с тем что нужно что-то усложнить или уже усложнено, я стараюсь первое время убежать из этого места. Моя жизненная позиция пока такова - я не считаю что нет безвыходных вариантов и нужно что-то усложнять или костылить. Всегда можно найти хороший вариант, с очевидным и не запутанным сценарием. В самом первом ответе, MsGuns, сразу дал ответ с которым многие согласятся.

Добавлено через 1 минуту

Сообщение от kotelok "1;2;3;4;5;6" => List<int>

Кстати вопрос - что мешает создать свойство с логикой распаковки? в сущности string, а в апи - list.

1

Сообщение от Usaga От того, что ТС не видит границы между хранилищем и бизнес-логикой.

Я вижу разницу. И в нынешнем решении оно полностью разделено, т.е. есть сущности бизнес-логики, есть прослойка в виде репозитория/датасервиса, которая сохраняет/восстанавливает эти сущности в/из хранилище. В данном случае это БД, в данном случае между БД и репозиторием имеется EF-контекст (один-в-один по наследным таблицам БД), и репозиторий сохраняет/восстанавливает сущности бизнес-логики через EF-сущности. Плюс экспериментальный вариант на SQL+Dapper.

Вторая часть вопроса уже относилась не к исходному сообщению, а к тому, как восстановить сущность с приватными сеттерами, если согласно логике данной сущности через параметры конструктора она все эти данные принимать не может. Безотносительно EF или ещё какого-то решения, EF тут был просто как вариант решения, которое умеет из коробки в приватные поля данные напрямую восстанавливать.

0

Может конечно и фигню сморожу, но для EF нужно только вот такое определение для выгрузки и сохранения данных
Получили данные (из одной, двух, трёх и т.д. таблиц) с помощью EF -> передаем в слой с БЛ -> там их ворочаем как нам нужно (собираем какие-то классы, списки, коллекции) всё это показываем пользователю, он правит, а потом всё в обратную сторону -> слой с БЛ все данные распихивает по классам данных -> EF это дело сохраняет.
EF это ведь только надстройка для ADO .NET, он не умеет в бизнес-логику, это только получи -> отследи -> сохрани назад.
Я так думаю (с) ...

1

kotelok, вы не поняли) То, что вы репозиториев всяких наделали с прослойками это понятно. Но у вас, получается, бизнес-логика (по сути валидация) отрабатывает сразу, по мере чтения и материализации данных. Т.е. этот процесс слит во-едино. Границы между этими процессами у вас нет.

А это приведёт к описанным ранее проблемам. В частности, к тому, что пользователь не сможет отредактировать данные. Как их будет техподдержка редактировать мне тоже не понятно. Просто потому, что в процессе чтения задействованы правила, которые должны отрабатывать перед сохранением...

Добавлено через 41 секунду

Сообщение от Andrey-MSK EF это ведь только надстройка для ADO .NET, он не умеет в бизнес-логику, это только получи -> отследи -> сохрани назад. Я так думаю (с) ...

Верно думаете.

1

Andrey-MSK,
Да, всё верно. Просто есть ещё немного другой подход под другие сценарии. Сам его не использовал, но видел несколько раз в статьях и презентациях.

Когда проектирование начинается не с базы даннных и её структуры, а именно с объектов бизнес-логики. Которые потом можно напрямую спроецировать на какое-то хранилище (которое будет на 100% соответствовать требованиям бизнес-объектов), описав EF/NHibernate-контекст прямо поверх этих сущностей посредством fluent-API (т.е. не нагружая сами сущности ORM-зависимостями). При этом ORM при восстановлении сущностей предполагает, что хранилищие не может быть повреждено извне, а потому восстанавливает значения свойств в обход бизнес правил записывая значения напрямую в backing fields через reflection.

Добавлено через 6 минут

Сообщение от Usaga А это приведёт к описанным ранее проблемам. В частности, к тому, что пользователь не сможет отредактировать данные. Как их будет техподдержка редактировать мне тоже не понятно. Просто потому, что в процессе чтения задействованы правила, которые должны отрабатывать перед сохранением...

Тогда получается традиционный вариант:
1. При запросе данных они (не суть как) попадают в какие-то DTO без какой-либо валидации на этапе чтения. Этот DTO уходит клиенту и как-то визуализируется (даже если там некорректные данные в силу ошибок хранилища или новых бизнес-правил).
2. Когда пользователь нажимает OK, то на сервер приходит какой-то DTO на базе которого сервис выполняет валидацию и, если всё ок, отправляет (не суть как) данные на сохранение.

У меня это просто очередная попытка натянуть 'always-valid rich-model' на реальное приложение. И пока не очень получается.

0

Сообщение от kotelok Тогда получается традиционный вариант: 1. При запросе данных они (не суть как) попадают в какие-то DTO без какой-либо валидации на этапе чтения. Этот DTO уходит клиенту и как-то визуализируется (даже если там некорректные данные в силу ошибок хранилища или новых бизнес-правил). 2. Когда пользователь нажимает OK, то на сервер приходит какой-то DTO на базе которого сервис выполняет валидацию и, если всё ок, отправляет (не суть как) данные на сохранение.

Да. Всё верно.

Сообщение от kotelok У меня это просто очередная попытка натянуть 'always-valid rich-model' на реальное приложение. И пока не очень получается.

И не получится. Это как сова с глобусом.

1

kotelok, Возможно, я ошибаюсь, но складывается такое впечатление:
Есть три "ипостаси" информации: хранение, представление(интерпретация) и отображение. Стоит задача реализовать нетривиальный алгоритм "трансформации" из одной "ипостаси" в другую, например, отобразить с последующей возможностью правки сложные данные, хранящиеся в базе как атомы (поле таблицы): json, xml, список, множество, массив, черт в ступе и т.д.
И Вы пытаетесь решить эту задачу сугубо через EF, который, грубо говоря, не для этого был сделан.
Можно, конечно, попробовать сделать зубочистку на пилораме, на зачем ?

0

MsGuns, не, тут немного другое. ТС захотел организовать соблюдение инварианта данных на всех стадиях жизни модели. В сущности, этот вопрос к EF'у отношения не имеет. Как и решения полного.

0

MsGuns,
Не, я просто, видимо, не очень конкретно вопросы задавал, потому недопонимание возникло. EF - чисто инструмент для сохранения/восстановления. Просто я предполагал через использование fluent-API немного сократить объём кода по явной ручной перегонке данных из базы в сущности предметной области. Ну и по результатам экспериментов, оно в целом работает. Т.е. можно прямо поверх доменной сущности реализовать EF/NHibernate-контекст, который будет её корректно сохранять/восстанавливать "как есть" (со всеми вложенными коллекциями, даже если все сеттеры приватные). И в идеальных условиях оно просто один-в-один на базу ложится. А в случае реализации нормальных доменных сущностей поверх древней базы, контекст может так же взять на себя немного дополнительной конвертации (чисто технической, как в примере из изначального поста, когда в базе данные кривовато хранятся).

Сообщение от Usaga И не получится. Это как сова с глобусом.

Просто про это последнее время так много говорят (и не только применительно к Шарпу) - на хабре статьи, на dotnext (и не только) доклады, он-лайн конференции и т.п., что решил посмотреть, может и в самом деле рабочая практика. Но на деле всё оказывается как-то слишком сложно. И даже на относительно простых реальных примерах сразу вылезают чисто технические сложности и приходится либо какие-то странные костыли изобретать, либо мириться с нарушениями инварианта на определённых этапах. Хотя, вероятно, на какие-то задачи оно хорошо ложится (хотя всё равно остаются чисто языковые проблемы). Говорят, правда, про DDD в целом, но по факту там всегда исключительно rich-model и максимальный упор на always-valid.

0

Сообщение от kotelok на хабре статьи, на dotnext (и не только) доклады, он-лайн конференции и т.п.,

Вы эта.. по помойкам не ходите, ладно

0

В общем, по итогам экспериментов всё свелось к ...

Сообщение от MsGuns Я голосую за второе, ибо EF слишком "заморочен" сам на себя

... т.к. даже при попытке описать всё через fluent-API, сущности всё равно приходится слегка подстраивать под особенности EF, а некоторые вещи выглядит странно, хоть и поддерживаются (например, конвертация нескольких полей БД в составной объект и обратно), или вообще не описуемы (например, конвертация имени колонки в ключ словаря и обратно). Полагаю, дальше будет всплывать ещё больше сложных моментов.

0

Сообщение от kotelok например, конвертация имени колонки в ключ словаря и обратно

Чего?..

0

Сообщение от Usaga Чего?..

Это когда вместо строк detail-таблицы создаются дополнительные колонки в master-таблице.

Т.е. удобно было бы сделать detail-таблицу с полями:
parameter_name (pk)
master_id (fk)
value_1
value_2
value_N

А вместо этого соорудили такое вот нагромождение полей в master-таблице:
parameter_one_value_1
parameter_one_value_2
parameter_one_value_N
parameter_two_value_1
parameter_two_value_2
parameter_two_value_N
....

0

Сообщение от kotelok Это когда вместо строк detail-таблицы создаются дополнительные колонки в master-таблице.

Так никто не делает)

Для сущностей с динамическим набором свойств заводят дополнительную таблицу, где каждая строка есть отдельное свойство с маркером типа этого свойства. Или просто в JSON\XML сериализуют это дело и пихают в одно поле.

А так как вы задумали, делать не надо. Это костылина. EF тут ни причём, что такую дичь не поддерживает.

0

Сообщение от Usaga Так никто не делает

Я знаю, но что есть, то есть, база-то наследная.

0

kotelok, какая разница откуда эта база взялась? База у вас? Код, который с ней работает, тоже? Так не проблема исправить этот момент. И тогда станет возможно использовать EF с такой таблицей. Убогие моменты можно и исправлять, а не подстраиваться под них.

0