Спасибо очень полезные ссылки, как раз я имел ввиду single table inheritance, в контекте вопроса про одну таблицу много классов.
Насчет маппинга имелось ввиду маппинг в самом проекте пример здесь: cpratt.co/using-automapper-getting-started
В базе данных у нас будет три таблицы Documents, DocumentLines, Product
>А для чего вам EF тогда?
Я имел ввиду не маппинг БД и ORM, а маппинг между сущностями Document и Order, DocumentLine и OrderLine.
>Любая нормальная ORM имеет возможность мапать коллекции элементов в том или ином виде. >Добавление позиции в коллекцию при правильном маппинге должно приводить к добавлению строк >в соответствующую таблицу с нужными значениями внешних ключей.
Безусловно, но если мы напрямую работаем с сущностью Document, но не Order.
> при чем чтобы таблица была одна?
Таблица Documents -> это абстракция для Order, Consignment, Return. То есть сериализация и материлизация на лету. Но этот вопрос я выяснил, Repository в любом случае должен передавать коллекцию объектов одного типа.
Функции на стороне сервера бд хороши, но, к сожалению, когда есть определенный уровень абстракции работы с базой данных, который при этом можно еще и легко протестировать, то думаешь именно о решении на стороне веб-сервера, а не на стороне сервера базы данных. Спасибо за ответ.
Добрый день, да, безусловно, понимание того что делает Linq to Entities есть. Но возможно есть возможность научить Linq распознавать этот метод и преобразовывать в sql код так, как Linq это делает с нативными функциями String.Contains, String.StartsWith и т. д. ?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.