Структуриране на голям проект за портлет Liferay

Започваме известна работа по голяма разработка на портлети с помощта на Liferay и ми е трудно да структурирам този проект по отношение на различни портлети, които създаваме. Не сме сигурни по какъв начин да структурираме нашия проект. Имаме разпределен екип за разработка по целия свят и използваме git като наше хранилище за версии. Ние използваме Spring Portlet MVC за разработване на портлети и използваме конструктор на услуги за слой услуги.

Мога да помисля за тези 3 подхода.

  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
Благодаря за вашето мнение. Мисълта ми за всеки проект на портлет е, че създава свой собствен военен файл и всеки може да изисква от нас да имаме всички зависимости на 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, предполагам. Бих искал да дам на всеки разработчик независим портлет dev env заедно с някои насоки за общи компоненти. По този начин те имат повече контрол върху своя код на портлет и се фокусират само върху конкретен код на портлет. В същото време общият код може да се нуждае от повече контрол, тъй като множество хора могат да го променят. - person Kzvi; 11.05.2011
comment
Това може да проработи .. стига да имате някой, който също пише общата бизнес логика ;-) Тъй като вашият екип е много разпръснат, аз лично смятам, че добра инфраструктура като Git (както вече споменахте) и средства за комуникация (бъг- /issuetracking, някакъв вид Wiki и т.н.) е много важно. Ако горният подход не работи (напр. ако откриете твърде много дублиране на код), все още можете да преструктурирате проектите, за да отговарят по-добре на нуждите на екипа (които може да се различават много, ако е толкова разпространен). - person Dirk; 11.05.2011