Bom dia,

Estou em um projeto novo e conhecendo o liferay.

Comecei criando um portlet com uma unica entidade. Funcionou bem a geração pelo service, porém achei a estrutura de classes muito complicada e chata.
Tentei evoluir e criar um relationamento many-to-many (Aplicativo e Categoria) e o service builder não consegue criar a tabela de relacionamento... já fiz tudo que foi indicado no forum e nada;

Gostaria de saber se tem outras pessoas usando uma camada de negócio própria, sem service builder do liferay. Seria algo como o JPA diretamente, ou outro framework...

Qual seria a justificativa para eu usar o service builder???

Boa noite Robson,

Quando eu começei a usar o Liferay eu também não via justificativa em usar o service builder mas com o tempo eu aprendi o seu valor e não troco por outro framework de persistência. Gosto das funcionalidades de cache, permissão e cluster awareness que vem out of the box com o service builder. Portanto o meu conselho é investir mais no aprendizado da ferramenta pois vale a pena no médio e longo prazo.

Abraço

Comecei com Liferay a pouco tempo dando manutenção no portal da empresa e também não via justificativa para usar o service builder. O problema é que, diferente do Thiago, quanto mais eu vejo código gerado pelo builder menos vontade tenho de continuar utilizando. Parece que o produto final do que ele faz fica obscuro. Isso dificulta a manutenção. Diria até que pode se tornar um pesadelo para o desenvolvedor.

Ao usar o service builder a atenção do desenvolvedor se concentra nas classes *LocalServiceImpl e *ServiceImpl (em caso de usar remote services) e no service.xml.

Focar em código gerado não é uma boa prática no Liferay e nem em nenhuma outra solução que decidas usar.

Penso que o ponto de vista possa ser outro. O propósito do service builder será melhorar a performance e o tempo de desenvolvimento do programador. Além disso, o código gerado pode depois ser adaptado às necessidades de cada um.

No entanto, penso que as coisas se tornam mais difíceis na hora de customizar queries. Requer um conhecimento elevado, e penso que por vezes é um pouco limitado.

Abraço

Não é esse o ponto. Concordo que a idéia do ServiceBuilder é boa. O foco do desenvolvedor fica onde agrega valor. O problema é que não é uma ferramenta madura o suficiente para ser usada em produção.

Usado em um banco de dados limpo, o ServiceBuilder é muito bonito. Faz tudo que promete. Porém, quando precisar alterar estrutura de tabelas, exige muito cuidado. Temos que lembrar de criar um arquivo chamado portal.properties no nosso classpath com a propriedade auto.upgrade desligada, caso contrário os registros são apagados. Gero os scripts de atualização de banco e rodo manualmente contra o banco. O desenvolvedor deveria se preocupar com isso?

Depois de algumas dores de cabeça com efeitos colaterais desse cara, minha recomendação é não usar em projetos novos. Para projetos legados, produza os scripts de alteração de banco para não ter surpresas desagradáveis.

Concluindo, acredito na idéia, mas não no que é o ServiceBuilder.

Att,
Rodrigo Martins

Também utilizo Liferay há um tempo, aproximadamente 3 anos, e lá no início também não entendia muito bem o por que de utilizar o Service Builder, pois achei muito complexo para utilizar o banco de dados.

Mas depois de um tempo, pesquisas e práticas, vi que para desenvolvimento de portlet, especificamente no Liferay é claro, este serviço agiliza e muito o desenvolvimento. Como já foi comentado anteriormente, o foco do desenvolvedor fica na lógica das regras de negócio, utilizando os *Impl, e o serviço cuida das demais preocupações como cache, etc. É extremamente recomendado utilizá-lo, principalmente quando o portal encontra-se em um ambiente clusterizado, pois o desenvolvedor não precisará implementar e configurar tudo o que for necessário para que as informações sejam propagadas através do cluster, já que com o ServiceBuilder vc não precisa configurar nada por padrão, a não ser algum tunning ou outro.

Concordo que para algumas coisas dá um certo trabalho, como utilizar uma query customizada, o que por sinal vem melhorando a cada versão. Mas, temos o mesmo "problema" em qualquer ferramenta, pois sempre temos necessidades que não se encaixam como uma luva no framework, dando trabalho para customizar, como já tive com JPA, Hibernate, até mesmo puro JDBC.

Já desenvolvi vários portlets que usam ServiceBuilder, das mais variadas complexidades, e até agora tive um problema sério, muito sério que foi simplesmente perder todas as informações de uma determinada tabela.

Depois de um tempo, após recuperar o backup que fiz antes de atualizar o portlet, vi que na verdade foi uma falha minha onde não defini o tamanho da coluna corretamente.

Fora este caso, o service ainda não me deixou na mão, com relação a perder informações ao ponto de ter que desabilitar o auto update.

Até agora o que mais me deu trabalho foi fazer relacionamento entre as entidades, o que no início achava que deveria ser mais "prático".

É interessante dar uma olhada no log e procurar por problemas durante a alteração da estrutura através do service builder, pois o mesmo pode estar encontrando dificuldades em executar a rotina devido a outros fatores como permissão, etc.

Alguns casos talvez possam ser resolvidos dando uma estudada mais aprofundada neste serviço, pois é bem extenso.

Resumindo, não estou defendendo que o ServiceBuilder é a única opção... mas para um portlet é o mais recomendado, principalmente com relação a outras questões como infraestrutura (cache, cluster), etc.

Olá Rodrigo,

Eu discordo veementemente que o Service Builder não esteja maduro o suficiente para produção pelo simples fato que o próprio Liferay é todo baseado no Service Builder. Acredito que os problemas que você enfrentou estejam relacionados a falta de conhecimento ou de reprodução do processo de deploy antecipadamente.
No cliente que venho trabalhando também encontramos alguns problemas na hora de alterar a estrutura das tabelas com o Service Builder mas pegamos esse problema muito antes de publicar em produção. O que fazemos para antecipar esse problema é ter no nosso ambiente de homologação ou desenvolvimento um dump diário do banco de dados de produção e em cima desse banco fazemos o deploy da nova versão do nosso portlet/web/hook com o Service Builder, esse processo é gerenciado automaticamente por uma instância do Jenkins. Se quiser posso compartilhar mais detalhes sobre a nossa solução.

Abraço

Olá Thiago,

Concordo com você em relação à falta de conhecimento na ferramenta. Comecei a pouco tempo com Liferay e o pouco código que vi é legado e talvez tenha sido construído de forma inadequada. Não era minha intenção desmerecer o ServiceBuilder. Apenas expus minhas impressões.

Abs