Location

O serviço de location tem como finalidade concentrar as informações de endereçamento e localidade do sistema. As informações de localidade são agredas por País, Estados, Cidades e Endereços (Logradouros). A partir deste conceito serão agregadas novas informações conforme a necessidade do sistema.

Principais Utilizações

Preenchimento automático por CEP

Por ter um cadastro completo das ruas do país, um dos principais serviços utilizados é a consulta de um endereço através do CEP para preenchimento automático em formulários. Ao utilizar esse serviço lembre-se de que algum CEP pode ainda não constar na base do serviço, e nesses casos deve-se permitir que o usuário complete os dados de Rua, Bairro, etc.. Isso impede que se use exclusivamente um relacionamento cegamente para o objeto de endereço.

Relacionamentos

Um relacionamento entre os objetos do sistema e o LocationAddressVO não é aconselhável, pois eles podem ser alterados ou corrigidos em uma atualização. O sistema deve conter seus próprios objetos para salvar o endereço. Além disso, o sistema deve prever a necessidade de se incluir um endereço (com CEP e ruas) que podem não constar no banco de dados ainda.

Já para os objetos LocationCityVO, LocationStateVO e LocationCountryVO um relacionamento não deve ser problema, pois esses objetos não devem ter atualizações tão frequentes. No caso apenas o relacionamento com o LocationCityVO fará todo o tamanho.

Estrutura de Dados

Endereços

• CEP
• Tipo (Avenida, Rua, Praça, Viela, Ladeira, etc.)
• Nome da Rua (Logradouro)
• Bairro
• Cidade

Cidade

• Nome
• Latitude (do Centro)
• Longitude (do Centro)
• DDD
• Código do IBGE
• Estado

Estado

• Nome
• Acrônimo (SP, BA, RS, etc.)
• Código do IBGE
• País

País

• Nome
• Acrônimo (br, ar, pt, etc.)
• Código BACEN

Persistindo ou Buscando Os VOs

Os objetos Location*VO fornecidos no framework tem RFWMetaAnnotations e se integram com o restante do Framework. Porém não tem nenhuma anotação do RFW.ORM. Caso utilize o módulo RFW.ORM, veja a sessão sobre o DAOResolver na página do RFWDAO. Há ferramentas que permitem informas o schema e a tabela implementando a interface DAOResolver, como a seguir:

Exemplo de utilização do DAOResolver para Persistir os LocationsVO

@Override public String getSchema(Class<? extends RFWVO> entityType, RFWDAOAnnotation entityDAOAnn) throws RFWException { // Informamos o Schama a ser utilizado para cada um dos objetos if (entityType.equals(LocationCountryVO.class)) { return "appSchema"; } else if (entityType.equals(LocationStateVO.class)) { return "appSchema"; } else if (entityType.equals(LocationCityVO.class)) { return "appSchema"; } else if (entityType.equals(LocationAddressVO.class)) { return "appSchema"; } return null; } @Override public String getTable(Class<? extends RFWVO> entityType, RFWDAOAnnotation entityDAOAnn) throws RFWException { // Informamos o nome da tabela de cada um dos objetos if (entityType.equals(LocationCountryVO.class)) { return "locationcountry"; } else if (entityType.equals(LocationStateVO.class)) { return "locationstate"; } else if (entityType.equals(LocationCityVO.class)) { return "locationcity"; } else if (entityType.equals(LocationAddressVO.class)) { return "locationaddress"; } return null; } @Override public String getMetaRelationColumn(Field field, RFWMetaRelationshipField ann) throws RFWException { // Informamos as colunas das FKs para o RFWDAO para cada relacionamento if (field.getDeclaringClass().equals(LocationAddressVO.class) && field.getName().equals(LocationAddressVO_._locationCityVO)) { return "idlocationcity"; } else if (field.getDeclaringClass().equals(LocationCityVO.class) && field.getName().equals(LocationCityVO_._locationStateVO)) { return "idlocationstate"; } else if (field.getDeclaringClass().equals(LocationStateVO.class) && field.getName().equals(LocationStateVO_._locationCountryVO)) { return "idlocationcountry"; } return null; }