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

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

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

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

    • Keeping each portlet in a separate portlet project can be easy and fast in development since I can have developers independently working on them.
    • Это может стать проблемой в тех случаях, когда портлеты используют общий код. Таким образом, в разных портлетах может быть большое количество кода одного и того же типа.
    • Это может выйти из-под контроля, поскольку у нас будет много файлов войны, и каждый из них увеличивает затраты времени выполнения.

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

    • This will reduce the number of portlet projects and lot of code can be reused.
    • В такую ​​структуру можно поместить некоторый контроль.

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

    • This will be most complicated to manage for distributed developer team.
    • Большую часть общего кода можно использовать повторно.
    • В этом случае проще обеспечить согласованность.

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

    • I would want to give each developer a independent portlet dev env along with some guidelines on common components.
    • Таким образом, они получают больший контроль над кодом своего портлета и сосредотачиваются только на коде конкретного портлета.
    • В то же время общий код может потребовать большего контроля, поскольку его могут изменять несколько человек.

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

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

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


project architecture structure portlet liferay-6
person Kzvi    schedule 11.05.2011    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

person Olaf Kock    schedule 30.07.2011

arrow_upward
1
arrow_downward

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

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

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

person Dirk    schedule 11.05.2011
comment
Спасибо за ваш вклад. Я считаю, что каждый проект портлета создает свой собственный файл war, и каждый может потребовать от нас наличия в нем всех зависимостей Spring. Что может быть связано с затратами времени выполнения. - person Kzvi; 11.05.2011
comment
В проекте много портлетов, которые связаны между собой и зависят друг от друга. Также они собираются использовать тот же уровень обслуживания, который мы планируем сохранить общим (как вы уже упомянули). - person Kzvi; 11.05.2011
comment
Мыслить громко, возможно, сохраняя всю пружину и другие зависимости на уровне нашего сервера приложений, может снизить затраты времени выполнения. - person Kzvi; 11.05.2011
comment
Если зависимости - единственная проблема: поскольку Liferay сам поставляется с миллиардом библиотек (включая Spring iirc), вы можете просто сослаться на них, используя liferay-plugin-package.properties (см. здесь, например.) - person Dirk; 11.05.2011
comment
Спасибо, в этом больше смысла. - person Kzvi; 11.05.2011
comment
Думаю, подход должен сочетать 1 и 2. Я хотел бы дать каждому разработчику отдельную среду разработки портлетов вместе с некоторыми рекомендациями по общим компонентам. Таким образом, они получают больший контроль над кодом своего портлета и сосредотачиваются только на коде конкретного портлета. В то же время общий код может потребовать большего контроля, поскольку его могут изменять несколько человек. - person Kzvi; 11.05.2011
comment
Это может сработать ... если у вас есть кто-то, кто также пишет общую бизнес-логику ;-) Поскольку ваша команда очень широко распределена, я лично считаю, что хорошая инфраструктура, такая как Git (как вы уже упоминали) и средства связи (ошибка- / Issueetracking, своего рода Wiki и т. д.) очень важно. Если описанный выше подход не работает (например, если вы обнаружите слишком много дублирования кода), вы все равно можете реструктурировать проекты, чтобы они лучше соответствовали потребностям команды (которые могут сильно отличаться, если это так широко). - person Dirk; 11.05.2011