«

»

Feb 08

Print this Post

Uma visão sobre arquitetura de softwares

Uma regra que deveria ser a primeira coisa pensada pelo desenvolvedor, mas que muitas das vezes nem é lembrada… é a arquitetura do software que se vai desenvolver.

Hoje é muito fácil ser “Desenvolvedor”, não é como profissões como medicina, engenharia, direito que deve-se ter uma formação para atuar. (Lembrando que existem casos, de médicos, engenheiros, advogados entre muitas outras profissões que o atuante não tem formação, mas é ilegal e ponto.)

No caso do desenvolvimento de software não, é recomendado que tenham uma formação, algumas empresas até exigem, mas muitas das vezes não é o caso.

O problema disso, é que muitas pessoas que fazem parte dessa regra são como fala um amigo, “Programadores por acaso”! Existe a exceção a regra gente, conheço, vários programadores que não tem formação e são melhores que muita gente ai que tem POS, Mestrado e etc…

Eu particularmente acho que o lado ruim dessa abertura na função é a falta de iniciativa dos que querem ser auto-didatas, acham que fazer um sistema para uma empresa, enquanto aprendem a programar sozinhos, é a solução. Mas isso gera sistemas legados com alto nível de complexidade de manutenção.

Já trabalhei com vários desses… E garanto não é nada bom. Já mexi em sistemas que tinham variáveis a, b, c, d… e a única regra é que variáveis “o” são instâncias de objetos, ou melhor, instâncias de classes … pois analisando essas classes, era complicado reconhecê-las como um objeto.

Por que eu falei sobre isso? Eu poderia falar muito mais a respeito do tema, mas só dei uma pincelada para mostrar a importância da arquitetura antes de começar a desenvolver.

Eu sei que em freelas, muitas das vezes, não temos como fazer analise, definir requisitos, entrevistar usuários, acompanhar o fluxo de trabalho, definir regras de gerenciamento de mudanças no escopo, e tudo mais… ficaria caro para o cliente e o mesmo contrata um freelancer justamente pelo custo do projeto.

Porém em empresas, principalmente em empresas de desenvolvimento é obrigatório ter profissionais para fazer todo tipo de analise antes de o desenvolvedor abrir a IDE favorita dele.

Mas, em freelas ou em empresas, a arquitetura de software não tem como ser deixada de lado. E o desenvolvedor auto-didata que está começando deve ter a cultura de entender, e aplicar regras da arquitetura. Em empresas de desenvolvimento, existe geralmente, setor de arquitetura de software, em alguns casos, são os caras mais feras em programação que fazem parte do “grupinho de feras”.

Trabalhei em uma empresa, em que um desenvolvedor de cada tecnologia fazia parte da arquitetura, e basicamente trabalhava, criando e definindo padrões e frameworks e resolvendo problemas que ninguém mais conseguia desenvolver… o famoso “Esquadrão Zumbi”, quem viu “Stallone Cobra”, vai entender a piada.

Eu até gosto desse modelo, uma equipe voltada para a arquitetura de software, e a visão de identificar bons profissionais para fazer parte da equipe, mas também acredito que todo desenvolvedor tem que ter um conhecimento apurado de arquitetura.

Bom, chega de conversa, e vamos falar de arquitetura

Arquitetura de Softwares

Muita gente quando fala de padrões, pensa logo “Qual Framework vou usar?”.

Eu acho importante a adoção de um framework, ou até o desenvolvimento de um, já adotei as duas práticas e vale realmente. Porém, em alguns casos, a utilização de um framework se torna prejudicial ao meu modo de ver.

Imaginem uma aplicação aberta ao publico, que recebe milhões de acessos dia, tabelas grandes, muito tráfico de dados, relacionamentos complexos, usar um framework com Hibernate, acho complicado.

Vejo nesse cenário a necessidade de uma boa estruturação de consultas, aplicação de regras onde não existam JOINs ou SubSelects de conteúdos pesados, ao invés disso o uso de sumarização de dados, otimização de consultas, tratamento de resultados e etc… coisas que com o Hibernate se torna complicado de fazer.

Então, em alguns momentos, eu vejo mais praticidade a modelagem de uma arquitetura própria do que a utilização de um framework. E criar sua própria arquitetura não é algo complicado, basta conhecer bem de Orientação a Objetos e de padrões (Design Pattern). Logicamente que existem muitos padrões, alguns mais complexos, outros nem tanto. Tendo um em mente já ajuda bastante.

Outra coisa que eu particularmente pratico, é não seguir fielmente o que o padrão determina, eu crio meus próprios padrões. O importante é, não ficar variando esse padrão, até por que se em cada aplicação você mudar, não é mais padrão.

Vou aproveitar, e detalhar um pouco algumas regras que sigo quando vou modelar meus softwares.

Pontos de Atenção

Quando vou iniciar o desenvolvimento de uma aplicação, eu passo meio que um “Check-List” a seguir.

  • Segurança;
    Analisar todos os critérios de segurança da aplicação. Que tipo de usuário vai acessar, como vai acessar, se vai ficar aberto, se tem envio de arquivos, quais formatos, definição de como proteger, do que liberar, níveis de acessos e etc.Não foi atoa que coloquei segurança como o primeiro item. É o mais importante, sua aplicação é a interface entre o usuário e os dados da empresa. É como botar um segurança na porta do prédio e a ordem para ele ser: “Entra quem quiser! Se você ouvir gritos venha nos ajudar.” Se você não se preocupar com a segurança da tua aplicação no início, você estará dando essa ordem para o seu segurança.E o pior, no caso de segurança na WEB, esse tipo de segurança na porta, costuma dormir… E nem ouvem os gritos!E as questões de segurança, já é assunto para um outro tópico, falar superficialmente do tema, não ajudaria tanto, mas fica a dica para a preocupação com segurança.
  • Desempenho;
    Assim como a Segurança da aplicação, o Desempenho é igualmente importante. Quando testamos uma aplicação assim que terminamos o desenvolvimento, está longe de mostrar a velocidade real da mesma. Só quando trabalhamos com aplicações que são acessadas milhões de vezes por dia, é que temos a real ideia do quanto é importante atentar para o desempenho da mesma.E quando falamos de desempenho, falamos de Consultas ao Banco, Listagem de dados para o cliente, tipo de solicitações, como solicitar dados, paginação de dados, cache, reaproveitamento de códigos, otimização de códigos, otimização de consultas, sumarização de dados, scheduler, clusterização, separação de recursos como tratamentos e processamentos, JOBS, Procedures e etc…Essa medição de desempenho, deve ser feita tanto na codificação da aplicação, quanto na criação das consultas ao banco de dados.Coisas como analise dos recursos da linguagem utilizados e comparação entre maneiras diferentes de implementação, ajuda muito a codificar aplicações rápidas.
    Alguns exemplos seriam:
    • Testar se fazer um loop em cima de um array ou converter esse array numa lista de strings para tratar como tal.
    • Implementações de consultas direto no banco, uso do EXPLAIN para entender como o banco está reagindo a consulta.
    • Testar quais recursos de conversão são mais rápidos em modo geral. ex: Conversão de datas na aplicação ou no banco.
    • Comparações numéricas e não com strings, ou seja, evitar de implementar: if( variavel == ‘email’ ) e sim fazer de forma que possa ser: if( isEmail == true ) ou if( bitEmail == 1 ).
    • Recursos como exportações, importações, geração de relatórios, tratamento de imagens, manipulação de planilhas, geração de estatísticas e etc… usar recursos de agendamento para horários de pouca utilização e sumarizar dados.
    • Consultas fixas, que sempre se repetem, usar views do banco de dados.
    • Pensar em recursos como: Stored Procedures, Views, Triggers e etc… Muitas vezes tira um pouco da carga da aplicação e usam pouco recurso do servidor de banco. Ps. Outras vezes não… requer avaliação.
    • Leia a documentação da linguagem que você utiliza para programar, e veja quais funções da mesma tem maior desempenho e passe a utilizá-las.
  • Escalabilidade;
    Muitas vezes quando pensamos em desenvolver algo, esquecemos de pensar, no que poderá ser necessário integrar num futuro para funcionar junto ou usar recursos de nosso software.Desenvolver de forma que facilite a reutilização de nosso aplicativo por softwares terceiros é algo extremamente importante.Um dia, seu cliente faz um contrato com uma empresa de ERP e precisa tornar a aplicação uma fonte de dados para esse ERP, se o software for escalável, facilmente implementa-se um webservices, ou se faz uma exportação de dados por xml e é feita a integração. Em outros casos, requer um árduo trabalho da equipe de desenvolvimento para implementar uma solução.Disponibilidade de consumo das classes da aplicação por JSON (Lógico lembrando da segurança), é algo muito aplicável, vejam as APIs mais utilizadas. São facilmente manipuladas via JavaScript.
  • Documentação;
    Esta documentação que estou abordando é documentação de código, comentários que identifiquem métodos, ações, recursos, algorítimos complexos, módulos, APIs, implementações… Um repositório de bugs, uma Wiki dos recursos, documentação das classes e muito mais.Muita gente acha que não precisa, que o programador deve saber ler um código e entender como funciona… sim, concordo, mas é muito melhor se tiver uma documentação que explique o que é um método e como utiliza-lo do que ter que descobrir.
  • Divisão das camadas da aplicação;
    Determino como camadas quatro camadas, que são elas: DAO, Model, Controller e View e para auxiliar essas camadas, eu uso o DTO(Data Transfer Object). DTO, trata-se de objetos com Getters e Setters que fazem a transferência de dados, entre a View e o DAO, lógica mente passando por todas as camadas, tanto na ida quanto na volta.Então vamos ver como fica essa divisão das camadas.DAO– Camada responsável pela interação com o Banco de dados, só a camada DAO faz consultas ao banco de dados, nenhuma outra camada, tem acesso a não ser por intermédio da camada DAO e somente a camada de Modelo (MODEL), pode instanciar um objeto DAO. Ou seja, o desenvolvedor jamais pode fazer uma instância de um Objeto DAO dentro de um CONTROLLER.Outra coisa importante, em minha modelagem, mesmo sendo responsabilidade do DAO interagir com o Banco de dados, não é responsabilidade dele, tratar dados, ele faz sim, toda a proteção para evitar invasões, acessos indevidos aos dados e etc… Mas a validação dos dados deve ser filtrado no DTO e no MODEL. Os dados devem chegar prontos no DAO, se houver problemas tem que parar no MODEL, se possível nem chegar ao MODEL.MODEL– Camada responsável por fazer solicitações ao DAO, eu gosto de utilizar a camada MODEL também para regras de negócios relacionadas ao Banco de dados, nunca regras ligadas ao retorno dos dados, somente regras que não sejam seguras para serem feitas a vista do cliente. Para casos de tentativas de ponte direta entre o VIEW/CONTROLLER ao DAO, não sejam aplicadas em com isso façam a requisição ser desconhecida para a camada de Dados(DAO).CONTROLLER – Esta camada é muito importante, por ela começa toda a segurança da Aplicação, ela recebe as solicitações dos clientes, e a ela cabe, identificar suas necessidades e chamar os recursos necessários para atender os pedidos. Tomando os devidos cuidados com a integridade e veracidade dos dados envolvidos.

    VIEW
    – Camada de visualização, faz a interação direta com o cliente, trata, prepara e exibe os dados da aplicação, faz as solicitações ao CONTROLLER e devolve para o usuário final.

    DTO
    – Como abordei acima, o DTO é uma maneira de trafegar informações, para evitar problemas e facilitar, em minha modelagem, quando um usuário envia um formulário na aplicação, o CONTROLLER não recebe um objeto FORM…  mas sim um DTO do tipo que o controlador espera. Numa tela de cadastro de usuários, o controlador recebe um DTO do tipo Usuarios(). 

    Uma grande vantagem do DTO, é que nele eu já tenho todo o tratamento dos dados, validações dos tipos e monto um objeto que é passado para o banco através do DAO. O retorno dos dados, quando voltam do DAO, podem chegar na VIEW novamente como um DTO como uma coleção de Usuarios() por exemplo. Ou como uma query mesmo… ai vem da necessidade e das questões de desempenho.

    Obs. Em alguns casos o DTO pode ser encontrados com as nomenclaturas: VO, BO, BEAN e afins.

  • Teste Unitário;
    A utilização de Testes Unitários, é algo que não sei mais programar sem fazer… A começar por erros bobos, de consulta, inserção e edição de dados… são resolvidos na hora de testar. Após fazer os testes unitários e receber o OK de funcionamento. A implementação fica mais prática, pois na hora de por exemplo, testar se o método implementado está funcionando, caso aconteça um erro, já temos uma certeza: “Os dados não inseriram, não é o DAO, algo está indo errado para o DAO”.E atentamos para a implementação do método e não para o método que salva no banco, eliminamos uma série de possibilidades.É chato implementar testes unitários, mas você acostuma depois que entender que está agilizando sua codificação.

Padrões que ajudar na reutilização de código

Quando se adota desenvolvimento em camadas, vocẽ acaba fazendo várias classes iguais, só mudando atributos, valores, nome, tipos e etc… para ajudar nisso, eu sigo alguns padrões.

  1. Uso Interfaces, que mapeiam o padrão da minha classe. Ex. “IDao”. Dessa forma, todos os meus DAOs devem implementar a Interface IDao e seguir o padrão (Esqueleto) da interface, garantindo que terei uma uniformidade de classes.
  2. Implemento classes bases. Ex. DaoBase. Essas classes, são estendidas pela classes filhas. A DaoBase é estendida pela classe Usuarios da camada DAO, dentro da classe base, tem toda a implementação que se repete… Implementações em comum não precisam ser re-feitas em todas as classes, só precisa estender a classe base e implementar os métodos como herança.
  3. Na modelagem das classes e do banco, sigo padrões, todas as tabelas seguem os mesmos padrões de nomenclatura de campos e atributos. Ou seja. A tabela usuários tem os campos: Id,Nome e etc… a tabela categorias tem os campos: Id, Nome e etc.
    Com isso em quase todos os casos, terei os campos Id e Nome, e em consequência disso todos os DTOs que representarem essas tabelas terão os atributos, getter e setters Id,Nome. Então se eu tenho um DTOBase, eu já posso ter a implementação dos atributos e getters e setters Id e Nome e herda-los do DTOBase.
  4. Outras coisas como Memento, Dump, Construtores, podem ser herdados das classes base.

Regras básicas

  • Não implementar HTMLs nas camadas Controller, Model, DAO e DTO.
  • Não retornar HTMLs.
  • Não fazer consultas fora da camada DAO.
  • Não chamar diretamente o DAO.
  • Não instanciar as classes bases, assim como ter uma classe base para cada camada.

Tem muitas outras coisas que devemos pensar e adotar, mas muita coisa vem do dia a dia, caso a caso, então é muito importante fazer uma analise do software em modo geral, quanto mais aprofundado for o seu comprometimento em desenvolver um software com uma arquitetura eficaz, melhor sairá o seu produto final.

Espero que esse material ajude desenvolvedores novos e quem sabe até os um pouco mais experientes.

Qualquer duvida estou as ordens.

Abraços a todos(as).

Paulo Teixeira
Post original

Uma regra que deveria ser a primeira coisa pensada pelo desenvolvedor, mas que muitas das vezes nem é lembrada… é a arquitetura do software que se vai desenvolver.

Hoje é muito fácil ser “Desenvolvedor”, não é como profissões como medicina, engenharia, direito que deve-se ter uma formação para atuar. (Lembrando que existem casos, de médicos, engenheiros, advogados entre muitas outras profissões que o atuante não tem formação, mas é ilegal e ponto.)

No caso do desenvolvimento de software não, é recomendado que tenham uma formação, algumas empresas até exigem, mas muitas das vezes não é o caso.

O problema disso, é que muitas pessoas que fazem parte dessa regra são como fala um amigo, “Programadores por acaso”! Existe a exceção a regra gente, conheço, vários programadores que não tem formação e são melhores que muita gente ai que tem POS, Mestrado e etc…

Eu particularmente acho que o lado ruim dessa abertura na função é a falta de iniciativa dos que querem ser auto-didatas, acham que fazer um sistema para uma empresa, enquanto aprendem a programar sozinhos, é a solução. Mas isso gera sistemas legados com alto nível de complexidade de manutenção.

Já trabalhei com vários desses… E garanto não é nada bom. Já mexi em sistemas que tinham variáveis a, b, c, d… e a única regra é que variáveis “o” são instâncias de objetos, ou melhor, instâncias de classes … pois analisando essas classes, era complicado reconhecê-las como um objeto.

Por que eu falei sobre isso? Eu poderia falar muito mais a respeito do tema, mas só dei uma pincelada para mostrar a importância da arquitetura antes de começar a desenvolver.

Eu sei que em freelas, muitas das vezes, não temos como fazer analise, definir requisitos, entrevistar usuários, acompanhar o fluxo de trabalho, definir regras de gerenciamento de mudanças no escopo, e tudo mais… ficaria caro para o cliente e o mesmo contrata um freelancer justamente pelo custo do projeto.

Porém em empresas, principalmente em empresas de desenvolvimento é obrigatório ter profissionais para fazer todo tipo de analise antes de o desenvolvedor abrir a IDE favorita dele.

Mas, em freelas ou em empresas, a arquitetura de software não tem como ser deixada de lado. E o desenvolvedor auto-didata que está começando deve ter a cultura de entender, e aplicar regras da arquitetura. Em empresas de desenvolvimento, existe geralmente, setor de arquitetura de software, em alguns casos, são os caras mais feras em programação que fazem parte do “grupinho de feras”.

Trabalhei em uma empresa, em que um desenvolvedor de cada tecnologia fazia parte da arquitetura, e basicamente trabalhava, criando e definindo padrões e frameworks e resolvendo problemas que ninguém mais conseguia desenvolver… o famoso “Esquadrão Zumbi”, quem viu “Stallone Cobra”, vai entender a piada.

Eu até gosto desse modelo, uma equipe voltada para a arquitetura de software, e a visão de identificar bons profissionais para fazer parte da equipe, mas também acredito que todo desenvolvedor tem que ter um conhecimento apurado de arquitetura.

Bom, chega de conversa, e vamos falar de arquitetura

Arquitetura de Softwares

Muita gente quando fala de padrões, pensa logo “Qual Framework vou usar?”.

Eu acho importante a adoção de um framework, ou até o desenvolvimento de um, já adotei as duas práticas e vale realmente. Porém, em alguns casos, a utilização de um framework se torna prejudicial ao meu modo de ver.

Imaginem uma aplicação aberta ao publico, que recebe milhões de acessos dia, tabelas grandes, muito tráfico de dados, relacionamentos complexos, usar um framework com Hibernate, acho complicado.

Vejo nesse cenário a necessidade de uma boa estruturação de consultas, aplicação de regras onde não existam JOINs ou SubSelects de conteúdos pesados, ao invés disso o uso de sumarização de dados, otimização de consultas, tratamento de resultados e etc… coisas que com o Hibernate se torna complicado de fazer.

Então, em alguns momentos, eu vejo mais praticidade a modelagem de uma arquitetura própria do que a utilização de um framework. E criar sua própria arquitetura não é algo complicado, basta conhecer bem de Orientação a Objetos e de padrões (Design Pattern). Logicamente que existem muitos padrões, alguns mais complexos, outros nem tanto. Tendo um em mente já ajuda bastante.

Outra coisa que eu particularmente pratico, é não seguir fielmente o que o padrão determina, eu crio meus próprios padrões. O importante é, não ficar variando esse padrão, até por que se em cada aplicação você mudar, não é mais padrão.

Vou aproveitar, e detalhar um pouco algumas regras que sigo quando vou modelar meus softwares.

Pontos de Atenção

Quando vou iniciar o desenvolvimento de uma aplicação, eu passo meio que um “Check-List” a seguir.

Segurança;
Analisar todos os critérios de segurança da aplicação. Que tipo de usuário vai acessar, como vai acessar, se vai ficar aberto, se tem envio de arquivos, quais formatos, definição de como proteger, do que liberar, níveis de acessos e etc.Não foi atoa que coloquei segurança como o primeiro item. É o mais importante, sua aplicação é a interface entre o usuário e os dados da empresa. É como botar um segurança na porta do prédio e a ordem para ele ser: “Entra quem quiser! Se você ouvir gritos venha nos ajudar.” Se você não se preocupar com a segurança da tua aplicação no início, você estará dando essa ordem para o seu segurança.E o pior, no caso de segurança na WEB, esse tipo de segurança na porta, costuma dormir… E nem ouvem os gritos!E as questões de segurança, já é assunto para um outro tópico, falar superficialmente do tema, não ajudaria tanto, mas fica a dica para a preocupação com segurança.
Desempenho;
Assim como a Segurança da aplicação, o Desempenho é igualmente importante. Quando testamos uma aplicação assim que terminamos o desenvolvimento, está longe de mostrar a velocidade real da mesma. Só quando trabalhamos com aplicações que são acessadas milhões de vezes por dia, é que temos a real ideia do quanto é importante atentar para o desempenho da mesma.E quando falamos de desempenho, falamos de Consultas ao Banco, Listagem de dados para o cliente, tipo de solicitações, como solicitar dados, paginação de dados, cache, reaproveitamento de códigos, otimização de códigos, otimização de consultas, sumarização de dados, scheduler, clusterização, separação de recursos como tratamentos e processamentos, JOBS, Procedures e etc…Essa medição de desempenho, deve ser feita tanto na codificação da aplicação, quanto na criação das consultas ao banco de dados.Coisas como analise dos recursos da linguagem utilizados e comparação entre maneiras diferentes de implementação, ajuda muito a codificar aplicações rápidas.
Alguns exemplos seriam:

Testar se fazer um loop em cima de um array ou converter esse array numa lista de strings para tratar como tal.
Implementações de consultas direto no banco, uso do EXPLAIN para entender como o banco está reagindo a consulta.
Testar quais recursos de conversão são mais rápidos em modo geral. ex: Conversão de datas na aplicação ou no banco.
Comparações numéricas e não com strings, ou seja, evitar de implementar: if( variavel == ‘email’ ) e sim fazer de forma que possa ser: if( isEmail == true ) ou if( bitEmail == 1 ).
Recursos como exportações, importações, geração de relatórios, tratamento de imagens, manipulação de planilhas, geração de estatísticas e etc… usar recursos de agendamento para horários de pouca utilização e sumarizar dados.
Consultas fixas, que sempre se repetem, usar views do banco de dados.
Pensar em recursos como: Stored Procedures, Views, Triggers e etc… Muitas vezes tira um pouco da carga da aplicação e usam pouco recurso do servidor de banco. Ps. Outras vezes não… requer avaliação.
Leia a documentação da linguagem que você utiliza para programar, e veja quais funções da mesma tem maior desempenho e passe a utilizá-las.
Escalabilidade;
Muitas vezes quando pensamos em desenvolver algo, esquecemos de pensar, no que poderá ser necessário integrar num futuro para funcionar junto ou usar recursos de nosso software.Desenvolver de forma que facilite a reutilização de nosso aplicativo por softwares terceiros é algo extremamente importante.Um dia, seu cliente faz um contrato com uma empresa de ERP e precisa tornar a aplicação uma fonte de dados para esse ERP, se o software for escalável, facilmente implementa-se um webservices, ou se faz uma exportação de dados por xml e é feita a integração. Em outros casos, requer um árduo trabalho da equipe de desenvolvimento para implementar uma solução.Disponibilidade de consumo das classes da aplicação por JSON (Lógico lembrando da segurança), é algo muito aplicável, vejam as APIs mais utilizadas. São facilmente manipuladas via JavaScript.
Documentação;
Esta documentação que estou abordando é documentação de código, comentários que identifiquem métodos, ações, recursos, algorítimos complexos, módulos, APIs, implementações… Um repositório de bugs, uma Wiki dos recursos, documentação das classes e muito mais.Muita gente acha que não precisa, que o programador deve saber ler um código e entender como funciona… sim, concordo, mas é muito melhor se tiver uma documentação que explique o que é um método e como utiliza-lo do que ter que descobrir.
Divisão das camadas da aplicação;
Determino como camadas quatro camadas, que são elas: DAO, Model, Controller e View e para auxiliar essas camadas, eu uso o DTO(Data Transfer Object). DTO, trata-se de objetos com Getters e Setters que fazem a transferência de dados, entre a View e o DAO, lógica mente passando por todas as camadas, tanto na ida quanto na volta.Então vamos ver como fica essa divisão das camadas.DAO- Camada responsável pela interação com o Banco de dados, só a camada DAO faz consultas ao banco de dados, nenhuma outra camada, tem acesso a não ser por intermédio da camada DAO e somente a camada de Modelo (MODEL), pode instanciar um objeto DAO. Ou seja, o desenvolvedor jamais pode fazer uma instância de um Objeto DAO dentro de um CONTROLLER.Outra coisa importante, em minha modelagem, mesmo sendo responsabilidade do DAO interagir com o Banco de dados, não é responsabilidade dele, tratar dados, ele faz sim, toda a proteção para evitar invasões, acessos indevidos aos dados e etc… Mas a validação dos dados deve ser filtrado no DTO e no MODEL. Os dados devem chegar prontos no DAO, se houver problemas tem que parar no MODEL, se possível nem chegar ao MODEL.MODEL- Camada responsável por fazer solicitações ao DAO, eu gosto de utilizar a camada MODEL também para regras de negócios relacionadas ao Banco de dados, nunca regras ligadas ao retorno dos dados, somente regras que não sejam seguras para serem feitas a vista do cliente. Para casos de tentativas de ponte direta entre o VIEW/CONTROLLER ao DAO, não sejam aplicadas em com isso façam a requisição ser desconhecida para a camada de Dados(DAO).CONTROLLER – Esta camada é muito importante, por ela começa toda a segurança da Aplicação, ela recebe as solicitações dos clientes, e a ela cabe, identificar suas necessidades e chamar os recursos necessários para atender os pedidos. Tomando os devidos cuidados com a integridade e veracidade dos dados envolvidos.
VIEW – Camada de visualização, faz a interação direta com o cliente, trata, prepara e exibe os dados da aplicação, faz as solicitações ao CONTROLLER e devolve para o usuário final.

DTO – Como abordei acima, o DTO é uma maneira de trafegar informações, para evitar problemas e facilitar, em minha modelagem, quando um usuário envia um formulário na aplicação, o CONTROLLER não recebe um objeto FORM…  mas sim um DTO do tipo que o controlador espera. Numa tela de cadastro de usuários, o controlador recebe um DTO do tipo Usuarios().

Uma grande vantagem do DTO, é que nele eu já tenho todo o tratamento dos dados, validações dos tipos e monto um objeto que é passado para o banco através do DAO. O retorno dos dados, quando voltam do DAO, podem chegar na VIEW novamente como um DTO como uma coleção de Usuarios() por exemplo. Ou como uma query mesmo… ai vem da necessidade e das questões de desempenho.

Obs. Em alguns casos o DTO pode ser encontrados com as nomenclaturas: VO, BO, BEAN e afins.

Teste Unitário;
A utilização de Testes Unitários, é algo que não sei mais programar sem fazer… A começar por erros bobos, de consulta, inserção e edição de dados… são resolvidos na hora de testar. Após fazer os testes unitários e receber o OK de funcionamento. A implementação fica mais prática, pois na hora de por exemplo, testar se o método implementado está funcionando, caso aconteça um erro, já temos uma certeza: “Os dados não inseriram, não é o DAO, algo está indo errado para o DAO”.E atentamos para a implementação do método e não para o método que salva no banco, eliminamos uma série de possibilidades.É chato implementar testes unitários, mas você acostuma depois que entender que está agilizando sua codificação.
Padrões que ajudar na reutilização de código

Quando se adota desenvolvimento em camadas, vocẽ acaba fazendo várias classes iguais, só mudando atributos, valores, nome, tipos e etc… para ajudar nisso, eu sigo alguns padrões.

Uso Interfaces, que mapeiam o padrão da minha classe. Ex. “IDao”. Dessa forma, todos os meus DAOs devem implementar a Interface IDao e seguir o padrão (Esqueleto) da interface, garantindo que terei uma uniformidade de classes.
Implemento classes bases. Ex. DaoBase. Essas classes, são estendidas pela classes filhas. A DaoBase é estendida pela classe Usuarios da camada DAO, dentro da classe base, tem toda a implementação que se repete… Implementações em comum não precisam ser re-feitas em todas as classes, só precisa estender a classe base e implementar os métodos como herança.
Na modelagem das classes e do banco, sigo padrões, todas as tabelas seguem os mesmos padrões de nomenclatura de campos e atributos. Ou seja. A tabela usuários tem os campos: Id,Nome e etc… a tabela categorias tem os campos: Id, Nome e etc.
Com isso em quase todos os casos, terei os campos Id e Nome, e em consequência disso todos os DTOs que representarem essas tabelas terão os atributos, getter e setters Id,Nome. Então se eu tenho um DTOBase, eu já posso ter a implementação dos atributos e getters e setters Id e Nome e herda-los do DTOBase.
Outras coisas como Memento, Dump, Construtores, podem ser herdados das classes base.
Regras básicas

– Não implementar HTMLs nas camadas Controller, Model, DAO e DTO.
– Não retornar HTMLs.
– Não fazer consultas fora da camada DAO.
– Não chamar diretamente o DAO.
– Não instanciar as classes bases, assim como ter uma classe base para cada camada.

Tem muitas outras coisas que devemos pensar e adotar, mas muita coisa vem do dia a dia, caso a caso, então é muito importante fazer uma analise do software em modo geral, quanto mais aprofundado for o seu comprometimento em desenvolver um software com uma arquitetura eficaz, melhor sairá o seu produto final.

Espero que esse material ajude desenvolvedores novos e quem sabe até os um pouco mais experientes.

Qualquer duvida estou as ordens.

Abraços a todos(as).

Permanent link to this article: http://ensina.me/coldfusion/uma-visao-sobre-arquitetura-de-softwares/

Leave a Reply