Entity Framework Merge Nightmare

Question

Мы приняли Entity Framework и обнаруживаем, что, когда несколько человек вносят отдельные изменения в свои отдельные ветви управления исходным кодом, возникают огромные конфликты, когда они собираются вместе в результате слияния, что приводит к повреждению файлов модели.

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

Мой вопрос ...

Есть ли лучший инструмент сравнения, который бы справился с этим лучше, или есть другой подход, который мы могли бы использовать?

Ищите что-то, что доказано, если это возможно.

НОВОЕ ОБНОВЛЕНИЕ: Для тех из вас, кто сталкивался с этим вопросом, он основан на старом EF. Я предлагаю перейти к использованию DbContext поверх EDMX. Здесь на SO много информации об этом. На мой взгляд, простота базы данных сначала или кода сначала намного перевешивает потерю дизайнера.

UPDATE: Мы решили эту проблему, принудительно внеся изменения в файл. Добавив этот процесс, мы полностью устранили все проблемы. Хотя это было не идеальное решение, оно было самым надежным и простым в реализации.

Answer 1

Крейг Штунц хорошо объясняет, что именно XML, связанный с дизайнером (положение сущностей и ассоциаций и т. Д. На поверхности дизайна), вызывает большинство проблем здесь. Однако разрешение конфликта внутри элемента edmx:Runtime вполне достижимо.

Лучшая стратегия для разрешения конфликтов в XML, связанном с конструктором, - полностью их обойти, пожертвовав любым пользовательским макетом и вернувшись к макету по умолчанию.

Хитрость заключается в удалении всего содержимого элемента <Diagrams>. Конструктор откроется без проблем и применит макет по умолчанию.

Ниже приведен пример файла EDMX, который открывается с макетом по умолчанию. Обратите внимание, что содержимое элемента <edmx:Runtime> также было удалено, однако это было сделано только для краткости - оно не является частью решения.

<?xml version="1.0" encoding="utf-8"?>
<edmx:Edmx Version="2.0" xmlns:edmx="http://schemas.microsoft.com/ado/2008/10/edmx">
  <!-- EF Runtime content -->
  <edmx:Runtime>
  <!-- Removed for brevity's sake only!-->
  </edmx:Runtime>
  <!-- EF Designer content (DO NOT EDIT MANUALLY BELOW HERE) -->
  <Designer xmlns="http://schemas.microsoft.com/ado/2008/10/edmx">
    <Connection>
      <DesignerInfoPropertySet>
        <DesignerProperty Name="MetadataArtifactProcessing" Value="EmbedInOutputAssembly" />
      </DesignerInfoPropertySet>
    </Connection>
    <Options>
      <DesignerInfoPropertySet>
        <DesignerProperty Name="ValidateOnBuild" Value="true" />
        <DesignerProperty Name="EnablePluralization" Value="True" />
        <DesignerProperty Name="IncludeForeignKeysInModel" Value="True" />
      </DesignerInfoPropertySet>
    </Options>
    <!-- Diagram content (shape and connector positions) -->
    <Diagrams>
    </Diagrams>
  </Designer>
</edmx:Edmx>

Обратите внимание, что применяемый здесь макет по умолчанию не совпадает с тем, который получается при выборе Diagram | Layout Diagram из контекстного меню дизайнера, чего я и ожидал.

Обновление: Начиная с Entity Framework 5 , это становится немного проще. Добавленная туда поддержка множественных диаграмм выгружает связанный с диаграммой xml в отдельные файлы. Обратите внимание, что у меня все еще были некоторые старые теги, связанные с диаграммами, в файле edmx, которые прошли ряд обновлений Entity Framework. Я просто удалил тег с именем Diagrams (включая дочерние) из файла edmx.

Answer 2

В этой статье есть несколько стратегий для работы с большими моделями Entity Framework . Вы могли бы рассмотреть возможность их использования. Тем не менее, я обнаружил, что большая часть боли при регенерации EDMX происходит от изменений, сделанных перетаскиванием в дизайнере GUI. С другой стороны, обновление модели из базы данных или через окно свойств имеет тенденцию вносить изменения довольно разумным образом, и объединение обычно не вызывает затруднений.

Самая большая проблема, насколько я могу видеть, заключается в том, что информация макета для визуальной объектной модели в концептуальных / картографических / хранилищных моделях находится в одном файле. Другими словами, проблема заключается не столько в размере самого файла или изменений, которые вносятся в саму модель объекта, но в полной перегруппировке, которая происходит при перетаскивании объекта в конструктор графического интерфейса. Я хотел бы, чтобы макет дизайнера графического интерфейса и концептуальные модели / модели отображения / хранения были в разных файлах. Я считаю, что это устранит большую часть боли с объединением изменений в модели.

Поэтому у нас есть полуофициальная политика не вносить изменения в графическое расположение модели. Это не большая потеря, потому что, когда в вашей модели более двух десятков объектов, конструктор графического интерфейса, состоящий только из одной страницы, в любом случае не очень полезен. И это, безусловно, значительно облегчает слияния.

Версия 4 Entity Framework будет иметь возможность создавать артефакты на основе шаблонов T4. Я не эксперт, но, возможно, можно получить информацию о разметке графического интерфейса в другой файл, используя шаблон T4.

Answer 3

Как вы сказали, одним из вариантов является блокировка файла.

Другой возможный вариант - направить все изменения модели через одного человека в команде.

Другой вариант - разбить файл на более мелкие файлы (например, по одному на класс), возможно, оставив позади некоторую поддержку дизайнера.

Другой вариант - создать свой собственный процесс, потенциально используя XSLT для преобразования файла EDMX, но я не уверен, как именно это будет выглядеть, файл designer.cs - это очень сложный для объединения файл.

Другой вариант - рассмотреть другой ORM.

Я не уверен, что они делают что-то, чтобы улучшить это в следующей версии EF. Сброс такого большого количества данных в один файл не подразумевает масштабируемость любого рода (однако LinqToSql делает то же самое - в этом случае Damien Guard создал несколько шаблонов T4, чтобы разбить файл на части, не уверенный, существует ли что-то подобное для EF).

Answer 4

Я действительно пытался убедить мою компанию пойти в Code First именно по этой причине, и, к сожалению, был закрыт. Им нравится иметь возможность использовать дизайнер. К сожалению, я столкнулся с проблемами в нашем последнем производственном развертывании, когда одна из наших служб WCF имеет около 10 конечных точек для поддержки нескольких потребителей, и в процессе объединения в разделе CS файла EDMX было несколько дублированных записей. .

В своих личных проектах я использую исключительно Code First. Для меня это та же самая причина, по которой я предпочитаю ручную коробку передач, а не автоматическую коробку передач. Конечно, дизайнер модели может быть проще (иногда, как мы уже говорили), но с Code First вы получаете гораздо более прямой контроль над тем, что происходит. Так же, как механическая коробка передач. :)

Answer 5

Я не очень хорошо знаком с EF, в частности, но у меня была немалая доля проблем с ультра подробным и хрупким автоматически генерируемым кодом. В каждом случае лучший ответ о том, как объединить это, было «не надо». В вашем сценарии это, вероятно, означает одну из двух вещей:

1) Укрепите модель продвижения кода, чтобы код EF работал только в одном направлении. Другими словами, каждый конфликт будет разрешен либо как «копия из исходной ветви» (AcceptTheirs), либо как «сохранить цель неизменной» (AcceptYours), и каждый должен знать, что есть что заранее. Чаще всего вам понадобится AcceptTheirs при продвижении недавно протестированного кода в направлении стабильных узлов дерева ветвей и AcceptYours при объединении исправлений обратно в нестабильные ветки / ветки разработки. (Если есть> 1 ветка разработки, вам нужно разделить вещи так, чтобы только код EF, принадлежащий команде, работающей в данной ветке, следовал последнему правилу. Все, что они не изменяют намеренно, должно быть переписано кодом других команд вытекает из ветви интеграции, используя AcceptTheirs, если это необходимо.)

               /- [...]
               /- v1.1
          /- Release<br>
    + Integration
          - Dev1
          - Dev2
          - [...]</p>

<p>

" Слияние, копирование вверх "

2) Буквально не сливать их; полностью исключить код EF из процесса. Когда для интеграции ветвей требуются изменения в базе данных и / или ORM, заново создайте прокси-классы непосредственно из базы данных. (после разрешения + построения любых конфликтующих изменений в ваших файлах SQL, конечно) Extreme version: делайте это при каждой автоматической сборке, а не только при слиянии.