Агнец за бортомEF при изменениях/откате миграции начинает пытаться переименовать объекты, и будучи не в состоянии дать какие-то уникальные имена - получает ошибку.

Банально надо лезть в файл миграции и расставлять инструкции в нужном порядке.

Это не пример текучести абстракции, стоит этого ожидать, даже если это будет человек, который должен будет искать ответ на вопрос: а что делать с именами?

Агнец за бортомИ в ходе рефакторинга - мы убираем свойство "заказы".
А потом опять пытаемся его же добавить.

И я не помню, что начинает происходить.

То ли EF сломается при добавлении связующих таблиц.
То ли EF замапит связь "не на ту таблицу".

Опять таки, EF не является искусственным интеллектом, и коллизии разрешить не в состоянии точно так же, как это не может сделать Git, который при конфликтующих изменениях просит человека выполнить правильное слияние.

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

Агнец за бортомВ общем - кончается тем, что надо "лезть" во fluent и мапить на таблицы там.

Нужно использовать классы конфигурации маппинга, для каждого Entity нужно создавать класс конфигурации, даже если Entity простой. Тогда не нужно лезть в какой-то одному Богу известный fluent.

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

Абстракции, тут как бы не при чём.

Агнец за бортомКак по мне - я не должен лазить в файл миграций. Тем более - еще его и править. Поэтому и течет.

Миграции к абстракциям как относятся? Если хочешь вообще жить без миграций и соответствующих проблем, ноу проблем, переходи на Raven, или MongoDB. Никаких миграций :)

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

Честно, не сталкивался с таким. Хотя в одном проекте у нас около 3 тыс. миграций.

Агнец за бортомА мои POCO - однозначны и согласованы. А EF "справится" с ними без вмешательства человека не может.

Ну конечно не может.

Было, допустим, у тебя поле Address. Потом ты его переименовываешь в PostAddress и добавляешь LegalAddress, считая, что EF должен догадаться, что PostAddress это бывший Address.

Агнец за бортомЯ считаю, что MS могла бы и получше сработать.

Ну, возможно.. Вообще, сейчас EF это опенсорс, если знаешь как лучше, велком в контрибьютеры.

Агнец за бортомВ смысле? Разве в конфигах используется не fluent?

Ну да, флюент. Но только применительно к своей модели.