...
- Mapeamento objeto relacional: através de frameworks como Hibernate, TopLink ou AO é possível mapear objetos no Java que reflitam as tabelas da base de dados.
- Controle Transacional (limitado): cada chamada HTTP é processada por um filtro de servlet que inicia uma transação, encaminha as operações e finaliza a transação se tudo ocorreu com sucesso. Se erros ocorrerem durante este processo toda a chamada é invalidada. Esta funcionalidade não possui suporte para transações aninhadas.
- Padronização de elementos UI através de classes CSS: o pacote AUI da Atlassian provê diversas classes para padronizar o laiaute de telas. Classes da arquitetura foram desenvolvidas para trabalhar em conjunto com este pacote e prover uma UI padronizada.
- Widgets (calendário, modal panel, tab panel): Diretivas tl-dialog, tl-tabset, tl-tab, tl-calendar fornecem widgets completos para o desenvolvimento de telas mais complexas e podem ser facilmente incorporadas a telas já existentes.
- Serialização/Deserialização genérica (podendo ser customizada pelo desenvolvedor): Todas as chamadas de operações CRUD são tratadas inicialmente pela arquitetura e esta é responsável pela serialização/deserialização das chamadas. Se houver uma sobrecarga destes métodos genéricos, os argumentos recebidos por estes métodos já são serializados e deserializados após o retorno, isto facilita a vida do desenvolvedor ocultando detalhes de serialização/deserialização.
- Validação de POJOS de forma genérica: toda chamada para métodos genéricos que provém operações CRUD são validadas automaticamente pela arquitetura. Esta validação pode ser visualizada no snippet do código da arquitetura abaixo.
| Bloco de código | ||
|---|---|---|
| ||
/**
* Given an object of type T, apply default object validation backed by JSR311 API. If T is a valid object, then return it,
* otherwise throws {@link org.treelayer.commons.business.exception.BusinessException} containing a map of constraint violations
* as follows:
*
* <p>
* {@code
* { "exampleEntity.name" -> "javax.validation.NotNull.message", "exampleEntity.id" -> "javax.validation.NotNull.message" }
* }
* </p>
*
* @param model object of type T that will be validated
*
* @return validated object
*
* @throws org.treelayer.commons.business.exception.BusinessException if object is not valid
*/
private T applyDefaultValidation(T model) throws BusinessException {
Map<String, String> constraintViolations = validatorUtil.applyValidation(model);
if (constraintViolations.size() > 0) {
throw new BusinessException(HttpURLConnection.HTTP_BAD_REQUEST, constraintViolations);
} else {
return model;
}
} |
- Tratamento de erros de forma transparente: exceções de negócio são lançadas utilizando a exceção customizada pela arquitetura BusinessException. Esta exceção é tratada pela camada mais externa e transforma as mensagens de erro em mensagens na tela do usuário, já internacionalizadas.
- Persistência transparente, idependente do framework de persistência utilizado (Hibernate, TopLink, AO): Todos os managers da arquitetura utilizam uma sólida base de classes que encapsula o framework de persistência utilizado. Com estas classes é possível abstrair as complexidades individuais de frameworks e oferecer assinaturas padrões para o desenvolvedor, não se importando com o framework utilizando.
Limitações
- Não suporta pilha de modal: temos na tela de Aplicações um relacionamento ManyToOne com Companhias. A tela de detalhe de aplicação constitui uma modal contendo todos os campos de aplicação e um combobox mostrando as companhias disponíveis. Com a atual arquitetura não é possível editar estas companhias a partir de uma aplicação. Para realizar esta operação seria necessário sobrepor a modal corrente de detalhe com uma modal de datalhe de companhia, controlando o fluxo de operações. A solução é abrir uma nova aba do navegador, realizar a operação e então continuar trabalhando com a aplicação em edição.
...