Если я Вас правильно понял Entity Framework-у можно объяснить, как мапить бизнес объект на таблицы? Интересует тот случай, когда бизнес объект — это несколько таблиц.
То есть сохраняем мы доменный объект, передаем его EF, а он автоматически распределяет данные хранящиеся в нем по разным таблицам.
Нужно понимать, когда используете EF, у вас больше нет слоя доступа к данным, сам EF это и есть слой доступа к данным.
А если Вам понадобится заменить реляционную БД на какой-нибудь другой тип хранилища, как Вы это сделаете? Нам ни что не мешает использовать EF с паттерном репозиторий. Тем более насколько я понимаю, сущность EF это не бизнес объект, а таблица БД и таким образом обращаясь к EF из бизнес логики, мы просто смешиваем логику БД с бизнес логикой. Поправьте меня пожалуйста если я не прав.
Даже такой простой пример стал сложнее и разделился на две части. Но эти части очень тесно связаны и такое разделение только увеличивает когнитивную нагрузку при чтении и отладки кода.
Возможно стоит правильно организовать структуру проекта, для того что бы по нему было удобно перемещаться и было интуитивно понятно где и что лежит, т.к на мой взгляд если писать жестко связанный код, то в случае большого проекта разобраться там будет еще труднее.
Насколько я помню в подобной литературе авторы пишут примерно о том, что да кода становится больше, но оно того стоит. Я думаю если есть такие книги, то такой подход проверен и работает, просто порог вхождения в него выше хотя бы потому, что многим может быть лень писать «Лишний код» (тоже самое касается тестов).
То есть сохраняем мы доменный объект, передаем его EF, а он автоматически распределяет данные хранящиеся в нем по разным таблицам.
А если Вам понадобится заменить реляционную БД на какой-нибудь другой тип хранилища, как Вы это сделаете? Нам ни что не мешает использовать EF с паттерном репозиторий. Тем более насколько я понимаю, сущность EF это не бизнес объект, а таблица БД и таким образом обращаясь к EF из бизнес логики, мы просто смешиваем логику БД с бизнес логикой. Поправьте меня пожалуйста если я не прав.
Возможно стоит правильно организовать структуру проекта, для того что бы по нему было удобно перемещаться и было интуитивно понятно где и что лежит, т.к на мой взгляд если писать жестко связанный код, то в случае большого проекта разобраться там будет еще труднее.
Насколько я помню в подобной литературе авторы пишут примерно о том, что да кода становится больше, но оно того стоит. Я думаю если есть такие книги, то такой подход проверен и работает, просто порог вхождения в него выше хотя бы потому, что многим может быть лень писать «Лишний код» (тоже самое касается тестов).