Histórico da Página

...

• 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.

/**
     * 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.

...