Как структурировать проекты для нескольких приложений Xamarin

Question

Моя команда работает над переводом нескольких устаревших мобильных приложений в приложения Xamarin Forms. В настоящее время каждое приложение представляет собой собственное решение, что не идеально, поскольку все они используют общий набор библиотек внутреннего программного обеспечения. Мы планировали объединить все более мелкие решения в единое решение, содержащее приложения, а также общие библиотеки.

Однако один из моих товарищей по команде высказал обоснованное беспокойство о том, как с помощью одного приложения Xamarin Forms, может быть сгенерировано несколько проектов (core, Android, iOS, et c.), что в конечном итоге приведет к в целом громоздкому решению. Я согласен с ним в том, что текущая настройка, вероятно, не будет слишком хорошо масштабироваться, поскольку мы добавляем больше приложений - даже если мы сгруппируем проекты в папках решений, Visual Studio в конечном итоге замедлит сканирование после того, как определенное количество проектов существует в решении.

Таким образом, мы рассматриваем возможность просто вернуться к тому, чтобы каждое приложение было отдельным решением, каждое решение содержит несколько проектов Xamarin Forms для этого приложения, как упоминалось выше. Но это возвращает нас к вопросу о том, как разумно управлять кодом разделяемой библиотеки. Моя текущая мысль заключалась бы в том, чтобы просто использовать общие проекты для библиотек или, возможно, собрать их в пакеты NuGet, которые будут потреблять решения приложений. Я на правильном пути, или кто-нибудь знает лучший способ сделать это?

Answer 1

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

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

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

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

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