Структурирование большого проекта портлета Liferay

Question

Мы начинаем некоторую работу по разработке большого портлета с использованием Liferay, и мне трудно структурировать этот проект с точки зрения различных портлетов, которые мы создаем.Мы не уверены, каким образом мы должны структурировать наш проект.Мы распределили команду разработчиков по всему миру и используем git в качестве хранилища версий.Мы используем Spring Portlet MVC для разработки портлетов и используем сервисный компоновщик для сервисного уровня.

Я могу подумать об этих 3 подходах.

1. Создание нового проекта портлета для каждого портлета

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

2. Логически разделить портлеты на количество проектов с портлетами

   • Это сократит количество проектов с портлетами, и много кода можно будет использовать повторно.
   • Некоторое управлениеможет быть помещен в такую ​​структуру.

3. Создать только один проект портлета со всеми портлетами

   • Это будет наиболее сложно для управления распределенной командой разработчиков.
   • Большую часть общего кода можно использовать повторно.
   • Обеспечение согласованности может быть проще в этом.

4. Смесь 1 и 2 (Основываясь на моем обсуждении с Дирком в комментариях ниже) Я думаю, что этот подход должен быть смесью 1 и 2.

   • Я хотел бы дать каждому разработчику независимую версию портлета вместе с некоторыми рекомендациями по распространенным компонентам.
   • Таким образом, они имеют больший контроль над своим кодом портлета и сосредотачиваются только на конкретном коде портлета.
   • В то же время общий код может нуждаться в большем контроле, поскольку его могут изменять несколько человек.

Я хотел бы узнать ваше мнение эксперта, если выуже создали проекты / портлеты liferay и какой подход вы выбрали.Помня об этом

• Как вы управляете разработкой портлетов, когда разработчиками разработано несколько портлетов.
• Каковы плюсы / минусы любого из вышеупомянутых подходов.
• Если ни один из вышеперечисленных подходов не подходит, пожалуйста, укажите наилучший подход, который вы можете придумать.

Спасибо за чтение

Answer 1

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

Кроме того, вы неплохо прибили варианты - ответ «посередине». Разделение баланса с использованием приложения-сервера. Используйте эмпирическое правило выше, и все готово.

Что касается сред разработки: каждый разработчик должен работать в своей собственной среде, однако посредством контроля версий он может, конечно, работать над одними и теми же проектами.

Answer 2

Я думаю, это в значительной степени зависит от того, какой проект вы на самом деле строите.Являются ли портлеты, о которых вы говорите, портлетами в смысле инкапсулированной функциональности и будут ли они использоваться как таковые (то есть, как, наконец, портлет в Liferay)?Они должны быть включены в разные проекты, на мой взгляд, если их функциональность не совпадает, и они не зависят друг от друга.

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

Как общий подход: что будетпроблема, позволяющая всем разработчикам иметь доступ ко всем (или большинству) проектам?Общий код может быть повторно использован всеми портлетами, и все же каждый должен будет работать только со своей стороны.