BISDAO Legacy

O BISCore oferece uma estrutura de persistência combinada com os recursos da JPA para simplificar a camada de persistência dos módulos. Essa estrutura prevê métodos para insert, update, delete e "find".

Para utilizar esta estrutura há algumas condições:

1. O objeto a ser persistido deve estender BISDefaultVO.
2. Para cada objeto a ser persistido, deve haver um MO correspondente, mesmo que sem qualquer atributo (classe vazia).
3. A classe de persistência deve estender BISDefaultEJB3DAO. Esta classe utiliza 'generics', e recebe como parâmetro as classes de VO e MO do objeto a ser persistido.
4. Deve ser Implementada uma interface deste DAO que por sua vez deve estender BISDefaultDAO.
5. Implementar o método no Factory do Plugin para retornar o objeto que implementa a interface do DAO.

Padrão de Nomes Para simplificação da programação em equipe e manutenção posterior lembre-se do padrão de nome dos objetos e classes adotados no BIS descritos no tópico Convenção de Nome do BIS.

Para exemplificar, imaginemos que o objeto em questão seja um "contato". Obviamente devemos ter o VO que o representa, se o objeto for batizado como "Contact" o nome do VO será ContactVO. Assim, para implementar a camada de persistência deste objeto devemos criar as seguintes classes e intarface:

• ContactMO: é o MatchObject utilizado nos métodos de busca automatizados do objeto. Este Objeto não precisa ter nenhum método, atributo ou construtor no seu interior a princípio. Seus atributos e métodos só precisam ser criados posteriormente de acordo com a necessidade de se realizar buscas do objeto.

ContactMO public class ContactMO extends BISDefaultMO { }

• ContactDAO: é uma interface que deve extender BISDefaultDAO, preenchendo seus generics com os MO e VO. Esta interface tem o objeto de separar e permitir que outras implementações de persistência funcionem de forma transparente, caso não se deseje mais utilizar o padrão EJB3DAO fornecido pelo BISCore (ou mesmo outro sistema de persistência fornecido pelo BISCore). Esta classe também não precisa ter conteúdo algum, já que sua implementação é herdada das classes do BISCore. Só terá implementação extra em objetos complexos ou que precisem de algum tipo de métodos para melhor performance ou execução de funções específicas.

ContactDAO public interface ContactDAO extends BISDefaultDAO<ContactVO, ContactMO> { }

• ContactEJB3DAO: Esta classe e a implementação da persistência usando o modelo EJB3DAO do BISCore. Assim como as outras classes não precisa ter nenhum conteúdo especial uma vez que todo o código já está implementado nas classes do BISCore. Mas criar a classe, implementa a interface definida acima e suprir os generics necessários.

ContactEJB3DAO public class ContactEJB3DAO extends BISDefaultEJB3DAO<ContactVO, ContactMO> implements ContactDAO { }

• <ModuleName>DAOFactory: Esta classe deve ser implementada apenas uma vez no módulo, por isso não usa o nome do objeto e sim o nome do módulo. Esta classe deve ter um método implementado para criar os DAOs do objeto e retorna-lo de acordo com o sistema de persistência usado no sistema.

Método de <ModuleName>DAOFactory public static AbbreviationDAO getAbbreviationDAO() throws BISCriticalException { if (DAOTYPE.EJB3HIB.equals(getDaotype())) { return new AbbreviationEJB3DAO(); } else { throw getUnsuportedDAOException(); } }

Objetos em Cadeia Se ContactVO contiver outros objetos (VOs) com informações, como por exemplo uma coleção de AddressVO, a camada de persistência criada para o ContactVO pode ser utilizado para realizar as operações em cadeia. Para isso precisa apenas fazer os mapeamentos do JPA entre os objetos.

Objetos em Cadeia Para o mesmo exemplo citado acima, um ContactVO que tenha uma coleção de AddressVO, não se deve persistir em cadeia caso o AddressVO seja um objeto autonomo, que seja cadastrado sozinho e tenha sua própria camada de persistência. Isto é, se AddressVO for utilizado apenas por este contato, se for apenas parte do ContactVO e não for manipulado em saparado do ContactVO, este deve ser persistido junto, em cadeia pelo Hibernate, afinal, a validação do objeto assim como toda sua manipulação deverá estar implementada nos métodos de manipulação do ContactVO. No entanto, se AddressVO é um objeto independente, que pode ser compartilhado entre outros ContactVO, cadastrado e manipulado independente do ContactVO, e para isso ter sua própria camada de persistência, ele nunca deve ser persistido junto com o ContactVO nem com outro objeto que faça referêcia. Para persisti-lo deve ser chamado o CRUD equivalente para fazer as validações e preparações necessárias antes de persisti-lo.

Uma vez que toda a estrutura esteja implementada, basta usar a Factory para obter a implementação correta do DAO (que será retornada apenas pela interface geral) e usar os métodos conforme descritos no JavaDoc do BISCore.

DAOFactory

A DAOFactory é uma a implementação do pattern Factory para a separação da camada de persistência da camada de lógica da aplicação. O pattern Factory obriga que uma única classe, aqui chamada com o sufixo Factory, implemente métodos que criem e retornem objetos identificados apenas por uma interface. Neste caso, nossa Factory é a DAOFactory, e seus métodos devem devolver as implementações dos DAOs de cada objeto de acordo com o tipo de persistência sendo utilizada. Por isso, só utilizamos uma única Factory por módulo. Esta factory terá um método para cada DAO criado no módulo. Cada DAO deve ser separado sempre em uma interface e uma ou mais implementações de acordo com a quantidade de modos de persistência que o módulo suportar.

A classe de DAOFactory da cada módulo deve ter o nome do módulo e o sufixo DAOFactory. Devem extender a classe BISDefaultDAOFactory para herdar os métodos que informam o tipo de persistência sendo usado pelo sistema. Uma DAOFactory implementada ficaria como o código abaixo:

<ModuleName>DAOFactory public final class BISCoreDAOFactory extends BISDefaultDAOFactory { //Métodos de getDAO() para retornar o DAO de cada objeto do módulo como mostrado na sessão anterior. }

BISOrderBy

O BISOrderBy é o objeto usado em conjunto com os MOs pela camada de persistência do BISCore para definir a ordem que os objetos devem ser retornados ao utilizarmos os métodos de find. Para criar o BISOrderBy é possível de duas maneiras: instanciando o objeto como qualquer outro, ou utilizando os métodos estáticos "getBISOrderbyInstance()". Em ambos os casos é possível passar dois atributos: coluna a ordenar e ascendência / descendência do campo. Por padrão, se passada só o nome da coluna, a ordem será ascendente. O nome da coluna a ser passada é o mesmo nome do atributo do VO.

Por exemplo, se temos um ClientVO, e queremos ordenar pelo atributo "name", devemos criar o BISOrderBy passando a string "name" como parâmetro. Se desejarmos que a ordem da lista seja de Z para A, devemos passar o segundo atributo como "false". Como o valor padrão é sempre true na ordem da lista, não faz sentido passar o segundo atributo para obter uma lista ascendente. É possível organizar uma lista por um atributo que esteja em um sub VO. Por exemplo, imaginando que nosso ClientVO tenha um atributo "address" que carregue um AddressVO, e este tenha um atributo para o nome da rua chamado "street". Para ordenar a lista de clientes por nome da rua, devemos criar um BISOrderBy passando como atributo a string "address.street". Lembrando que o find a ser utilizado é de Client, e não de address.

Criando Constantes Um dos possíveis problemas de se passar o nome do atributo como string é um futuro refactor ou alterações do código que venham a alterar o nome da coluna/atributo do VO. Quando isso ocorre, mesmo mudando os métodos Get e Set o nome do atributo passado na String não é validado pelo builder e gerará erro de RunTime já que o atributo não será encontrado no VO. Para evitar esse tipo de problema, recomendamos que os atributos usados comumente para ordenação da lista sejam colocados como constantes no MO. Desta forma ficam concentrados nas classes de VO as string de ordenação. Mesmo assim, nos casos de atributos em cadeia, como o nosso "address.street" não estará visível no objeto AddressMO, e sim no ClientMO. Por isso a melhor maneira é evitar o refactor de nomes de atributos, e como evitar? Pensar bem antes de defini-los. Se não houver hipóteses e houver mesmo a necessidade de um refactor, lembre-se sempre de fazer pesquisar no código por texto com o nome do atributo.

Para ordenar por múltiplas colunas, basta chamar os métodos "addOrderbyItem()" e passar os mesmos atributos citados acima, ou um BISOrderBy completo. A ordem em que estes são acrescentados define a prioridade de cada coluna, ou seja, a segunda coluna só será utilizada se houver empate na primeira, a terceira só será usada de houver empate na primeira e segunda, e assim por diante.

Criando BISOrderBy //Ordenando por uma coluna BISOrderBy.getBISOrderbyInstance(AbbreviationMO.ORDERBY_PRIORITY); //Ordenando por uma coluna de for descendente BISOrderBy.getBISOrderbyInstance(AbbreviationMO.ORDERBY_PRIORITY, false); //Ordenando por duas colunas BISOrderBy.getBISOrderbyInstance(AbbreviationMO.ORDERBY_PRIORITY, false).addOrderbyItem(AbbreviationMO.ORDERBY_OCCURENCE);