Задачка:

- есть неприятная база данных. Неприятность ее очень разная - от "не правильных имен" полей и таблиц, до отсутствия и невозможности нарисовать реляции.

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

- структура этих сложных объектов до конца не определена. Т.е. на сегодня Я знаю только ту часть структуры объектов, с которой доводилось работать.

- предстоит миграция на новую базу. База - совершенно другая по структуре и имеющиеся наработки никак не подойдут.

Вопросик 1 - можно ли используя ЕФ6 построить интересующую меня модель и связать ее с имеющейся базой?

Повторюсь - прямого отображения модели на базу не будет - нужно что-то большее чем ОРМ.

Вопросик 2 - если не ЕФ6, то чем можно пользоваться?

Типичная проблема: в Заказе есть юнит-сборка из двух панелей. Внешняя панель - двух-... иногда - трех- слойная склейка, внутренняя - однослойное стекло. Информация об однослойном стекле хранится в 3-4 таблицах, информация об сборке - в десятке других. При этом сами таблицы и в первом и во втором случаях - не фиксированные - зависят от того какое именно используется стекло и как его нужно обрабатывать.

Чем это можно покрыть?

Т. е. вам нужно ввести свой слой (application layer). Вероятно, что придётся развить этот слой до полноценного репозитория. Т. е. этот новый слой будет получать из другого слоя или из внешнего мира объект, соответствующий вашей бизнес-логике (например, ваша "внешняя панель"), и как-то раскидывать его по таблицам вашей старой базы данных. Также и с получением данных из этой БД - чтобы собрать объект вашей бизнес-логики, вам нужно будет сделать комплексный запрос к вашей старой БД.

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

Лучше, конечно, переработать старую БД под новую - с реляциями и более соответствующую вашей бизнес-логике, чтобы не надо было заниматься сложными преобразованиями объектов между слоями.

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