none
Desenvolvimento OO vs. Modularização

    Question

  • Saudacoes amigos,

    Li algumas mensagens neste forum e gostaria de saber a opiniao de voces no que tange a arquitetura e consequente construcao de aplicacoes (Visual Basic .NET & cia).

    Ficamos "orgulhosos" quando dizemos que o Visual Studio .NET eh totalmente OO. Entretanto, pelo menos eu, continuo desenvolvendo orientado a eventos e com codigo modularizado. Confesso que tenho dificuldade em ver uma solucao "OO" para um problema como uma tela de cadastro.

    Ja li sobre Application Blocks, sobre o NHibernate etc.. Mas gostaria de saber a opiniao de voces enfocando a arquitetura da solucao. 3 camadas para uma aplicacao Desktop (cliente-servidor) nao eh "exageiro"?

    Tenho varios "modulos" com rotinas genericas para montagem de sql, configuracao de interface etc.. Mas "sinto" como se estivesse "subutilizando" a minha, agora, ferramenta OO. Pura e simplesmente transformar o modulo em classe (sem persistencia) tambem nao me conforta... Gostaria de ouvir a voz das vossas experiencias.

    Um forte abraco a todos...

    Thursday, September 14, 2006 4:00 PM

Answers

  • Olá M. França,

            Bom, a OO traz diversas vantagens, entre as principais a facilidade na manutenção e no desenvolvimento. De uma maneira geral a estrutura do seu sistema fica muito melhor. Porém se vc tem uma aplicação que é estruturada ou orientada a eventos e esta funcionando sem problemas, dando pouco manutenção etc, daí nesse caso creio que não vale a pensa converter para OO, mas é tudo uma questão de avaliar a viabilidade de converter seu sistema, o tempo para essa conversão poderá ser alta mas poderá compensar pela rapidez na manutenção e por vc ter a possibilidade de utilizar todos os recursos de OO e do Visual Studio também.
          

    espero ter ajudado
    att
    Henrique Gurgacz


    Thursday, September 14, 2006 8:35 PM
  • Olá a todos,

      França, acho que tenho dúvidas semelhantes as suas, e confesso que até hoje não consegui me livrar completamente delas.

      Quando tentei dar meus primeiros passos na OO, ainda em VB6, com o pouco suporte que ele oferece, notei que minha modelagem OO era um reflexo do meu modelo de dados. Para cada tabela no banco de dados, eu tinha uma classe no sistema. E esta era geralmente composta por uma propriedade para cada atributo da tabela, e sempre com os métodos Inserir, Excluir, Abrir e Alterar.

      Quando há regras de negócios complexas, fica muito mais fácil imaginar classes colaborando entre si dentro do sistema, mas para aquele simples cadastro como citou, realmente é difícil saber .

      Ainda no VB6, acredito que minha maior conquista através de técnicas de OO, foi criar uma classe genérica para acesso a dados, que possuia um controle robusto de transações, executava queries assíncronas, métodos para retornar recordsets desconectados, além de conectar-se no banco apenas quando necessário.

      Mas minha principal dúvida ainda hoje é justamente como estruturar a camada de persistência:

      - A classe com a regra de negócio é quem deve gravar no banco?

     - É preciso criar uma classe de persistência para cada tabela, e esta por sua vez conversar com a classe de negócio?

    - A classe de negócio deve saber montar Selects e Inserts?

     Bem, estas são minhas dúvidas, espero que os comentários tragam algumas idéias para resolvê-las.

    Abraços,

     

     

     

     

     

     

     

     

     

    Thursday, October 19, 2006 5:11 AM
  • Olá senhores,

    Compartilhei durante algum tempo a mesma dúvida que vocês. Vamos colocar alguns pontos importantes:

    1. Orientação a eventos Orientação a Objetos e Camadas são ESTILOS de arquitetura de software, ou seja, quando você monta sua solução, você utiliza um ou mais estilos para atender aos requisitos de arquitetura.

    2. Programar orientado a objetos significa ter um conjunto de classes que se relacionam e trocam mensagens entre si, sendo que, os requisitos do seu sistema são distribuidos entre as classes, ou seja, cada classe tem apenas UMA responsabilidade

    Para entender o estilo em camadas, olhemos para ele como uma cebola. A cebola contém niveis de abstração e o um nível conhece apenas o nível logo abaixo dela, ou seja, a Camada de Negócios (BLL) conhece apenas a Camada de Dados (DAL).

    Para entender como a OO funciona, imagine uma empresa. Provavelmente ela tem um Presidente, um ou mais gerentes e um ou mais funcionários. Imagine um funcionário fazendo o trabalho de um Presidente ou ainda o Presidente fazendo o trabalho de um funcionário. Não ia dar certo, pois o funcionário não sabe (e não deve) conhecer as peculiaridades do serviço do Presidente, e vice-versa.

    No mundo OO a idéia é a mesma. A classe de ACESSO A DADOS (DAL) de PRODUTOS, deve saber apenas como ler e gravar informações da tabela PRODUTOS no banco de dados. A classe de NEGÓCIOS (BLL) de PRODUTOS, deve saber como funciona o PRODUTO para o NEGÓCIO (fazer calculos, verificações, sequencia de persistencia, etc). A classe de APRESENTAÇÃO (ASPX por exemplo) apenas sabe como CONVERSAR com o USUÁRIO e para cada ação desde, se essa não for referente a LÓGICA DE VISUALIZAÇÃO DA INFORMAÇÃO, DELEGA a responsabilidade para a classe de NEGÓCIO.

    Entenda que em cada CAMADA temos CLASSES que se RELACIONAM e possuem RESPONSABILIDADES distintas.

    Vantagem?
    1. Diminui a complexidade do código de cada classe;
    2. Diminui a quantidade de código em cada classe;
    3. Facilita a inclusão ou correção de funcionalidade;

     

    Abraços,

    Friday, December 15, 2006 7:37 PM
  • Como o Thiago falou sobre DAL's (acesso à dados) e BLL's (regra de negócios), venho aqui disponibilizar um link da Microsoft que possui um documento (em inglês) que explica como modelar essas camadas e como definir as suas entidades de negócio. Dessa forma você não precisa criar uma DAL + BLL para cada tabela. É legal ler sobre isso.

    Designing Data Tier Components and Passing Data Through Tiers
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

    Caso não gostem muito do inglês, o Fábio Serratto disponibilizou parte deste documento em português nos endereços a seguir:

    Arquitetura .Net - Camada de componentes de acesso a dados
    http://www.imasters.com.br/artigo/3763/dotnet/arquitetura_net_-_camada_de_componentes_de_acesso_a_dados/

    Arquitetura .Net - Camada de componentes de acesso a dados - Parte 02
    http://www.imasters.com.br/artigo/3815/dotnet/arquitetura_net_-_camada_de_componentes_de_acesso_a_dados_-_parte_02/

     

    Vale a pena conferir.

    Thursday, December 21, 2006 11:56 PM
  • Esse assunto da um pano pra manga... :)

    Eu acho que no mundo da arquitetura não existe "certo" ou "errado". Então você pode ou não usar uma abordagem OO "academicamente elegante", n-camadas ou seja lá o que for, e isso não vai definir se sua arquitetura é boa ou ruim.

    Contanto que você alcance algo que lhe proporcione:

    1-Abstração, ou seja, métodos simples de entender e de dar manutenção

    2-Performance

    3-Facilidade em reutilizar o que já foi escrito

    4-Facilidade em adaptação da sua equipe de desenvolvimento àquele ambiente

    5-Produtividade

     

    Ta bom demais! Pode ser OO? Pode. Pode não ser? Pode também.

     

    Esse seu sentimento de que poderia estar fazendo uma arquitetura mais interessante é ótimo, investigue e veja onde pode chegar. Mas nunca cometa o erro de usar algo só porque todo mundo diz que é bacana. Arquitetura demais é tão ruim quanto arquitetura de menos. Se você decidir mudar algo no que tem funcionado bem pra você, mude somente com boas justificativas na sua realidade.

    Agora, a má notícia é que sempre você vai olhar pra tras e dizer: Eh, dava pra fazer ainda melhor...

    ;)

    Monday, January 22, 2007 8:01 AM

All replies

  • Olá M. França,

            Bom, a OO traz diversas vantagens, entre as principais a facilidade na manutenção e no desenvolvimento. De uma maneira geral a estrutura do seu sistema fica muito melhor. Porém se vc tem uma aplicação que é estruturada ou orientada a eventos e esta funcionando sem problemas, dando pouco manutenção etc, daí nesse caso creio que não vale a pensa converter para OO, mas é tudo uma questão de avaliar a viabilidade de converter seu sistema, o tempo para essa conversão poderá ser alta mas poderá compensar pela rapidez na manutenção e por vc ter a possibilidade de utilizar todos os recursos de OO e do Visual Studio também.
          

    espero ter ajudado
    att
    Henrique Gurgacz


    Thursday, September 14, 2006 8:35 PM
  • Fala Henrique,

    Na verdade, meu questionamento eh mais abrangente. Parta do principio que voce esta desenvolvendo uma nova aplicacao - e nao necessariamente uma aplicacao "grande". Tomemos como exemplo um controle integrado de Compras e Estoque (materiais, fornecedores, cotacoes, pedidos, e/s etc.). Como venho da escola do VB6, minha visao eh essencialmente orientada a modulos de codigo (abertura de dataset, configuracao de grids) e eventos...

    Meu questionamento vem daí. Agora, utilizo o VB.NET que é uma ferramenta totalmente OO. Poxa, entao eu nao devia mudar meu paradigma? E no que tange a arquitetura (assunto desta thread), qual seria o ideal? 2 camadas? Formularios -> camada de interface e regras de negocio + Classes -> persistencia no banco... 3 camadas nao eh exageiro???

    Vou mais longe (pergunta de novato): Mas o ADO.NET ja nao prove as classes para a persistencia, ou seja, nao poderia considerar o ADO.NET como sendo minha "camada de persistencia"? Ou preciso parar e pensar: "classe Fornecedor". Que metodos e propriedades devo construir (pensando numa classe de persistencia).

    E por aih vai... (aguardo novos comentarios de todos)

    Abraços,

    Friday, September 15, 2006 2:06 PM
  • Olá a todos,

      França, acho que tenho dúvidas semelhantes as suas, e confesso que até hoje não consegui me livrar completamente delas.

      Quando tentei dar meus primeiros passos na OO, ainda em VB6, com o pouco suporte que ele oferece, notei que minha modelagem OO era um reflexo do meu modelo de dados. Para cada tabela no banco de dados, eu tinha uma classe no sistema. E esta era geralmente composta por uma propriedade para cada atributo da tabela, e sempre com os métodos Inserir, Excluir, Abrir e Alterar.

      Quando há regras de negócios complexas, fica muito mais fácil imaginar classes colaborando entre si dentro do sistema, mas para aquele simples cadastro como citou, realmente é difícil saber .

      Ainda no VB6, acredito que minha maior conquista através de técnicas de OO, foi criar uma classe genérica para acesso a dados, que possuia um controle robusto de transações, executava queries assíncronas, métodos para retornar recordsets desconectados, além de conectar-se no banco apenas quando necessário.

      Mas minha principal dúvida ainda hoje é justamente como estruturar a camada de persistência:

      - A classe com a regra de negócio é quem deve gravar no banco?

     - É preciso criar uma classe de persistência para cada tabela, e esta por sua vez conversar com a classe de negócio?

    - A classe de negócio deve saber montar Selects e Inserts?

     Bem, estas são minhas dúvidas, espero que os comentários tragam algumas idéias para resolvê-las.

    Abraços,

     

     

     

     

     

     

     

     

     

    Thursday, October 19, 2006 5:11 AM
  • Olá senhores,

    Compartilhei durante algum tempo a mesma dúvida que vocês. Vamos colocar alguns pontos importantes:

    1. Orientação a eventos Orientação a Objetos e Camadas são ESTILOS de arquitetura de software, ou seja, quando você monta sua solução, você utiliza um ou mais estilos para atender aos requisitos de arquitetura.

    2. Programar orientado a objetos significa ter um conjunto de classes que se relacionam e trocam mensagens entre si, sendo que, os requisitos do seu sistema são distribuidos entre as classes, ou seja, cada classe tem apenas UMA responsabilidade

    Para entender o estilo em camadas, olhemos para ele como uma cebola. A cebola contém niveis de abstração e o um nível conhece apenas o nível logo abaixo dela, ou seja, a Camada de Negócios (BLL) conhece apenas a Camada de Dados (DAL).

    Para entender como a OO funciona, imagine uma empresa. Provavelmente ela tem um Presidente, um ou mais gerentes e um ou mais funcionários. Imagine um funcionário fazendo o trabalho de um Presidente ou ainda o Presidente fazendo o trabalho de um funcionário. Não ia dar certo, pois o funcionário não sabe (e não deve) conhecer as peculiaridades do serviço do Presidente, e vice-versa.

    No mundo OO a idéia é a mesma. A classe de ACESSO A DADOS (DAL) de PRODUTOS, deve saber apenas como ler e gravar informações da tabela PRODUTOS no banco de dados. A classe de NEGÓCIOS (BLL) de PRODUTOS, deve saber como funciona o PRODUTO para o NEGÓCIO (fazer calculos, verificações, sequencia de persistencia, etc). A classe de APRESENTAÇÃO (ASPX por exemplo) apenas sabe como CONVERSAR com o USUÁRIO e para cada ação desde, se essa não for referente a LÓGICA DE VISUALIZAÇÃO DA INFORMAÇÃO, DELEGA a responsabilidade para a classe de NEGÓCIO.

    Entenda que em cada CAMADA temos CLASSES que se RELACIONAM e possuem RESPONSABILIDADES distintas.

    Vantagem?
    1. Diminui a complexidade do código de cada classe;
    2. Diminui a quantidade de código em cada classe;
    3. Facilita a inclusão ou correção de funcionalidade;

     

    Abraços,

    Friday, December 15, 2006 7:37 PM
  • Como o Thiago falou sobre DAL's (acesso à dados) e BLL's (regra de negócios), venho aqui disponibilizar um link da Microsoft que possui um documento (em inglês) que explica como modelar essas camadas e como definir as suas entidades de negócio. Dessa forma você não precisa criar uma DAL + BLL para cada tabela. É legal ler sobre isso.

    Designing Data Tier Components and Passing Data Through Tiers
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

    Caso não gostem muito do inglês, o Fábio Serratto disponibilizou parte deste documento em português nos endereços a seguir:

    Arquitetura .Net - Camada de componentes de acesso a dados
    http://www.imasters.com.br/artigo/3763/dotnet/arquitetura_net_-_camada_de_componentes_de_acesso_a_dados/

    Arquitetura .Net - Camada de componentes de acesso a dados - Parte 02
    http://www.imasters.com.br/artigo/3815/dotnet/arquitetura_net_-_camada_de_componentes_de_acesso_a_dados_-_parte_02/

     

    Vale a pena conferir.

    Thursday, December 21, 2006 11:56 PM
  • Esse assunto da um pano pra manga... :)

    Eu acho que no mundo da arquitetura não existe "certo" ou "errado". Então você pode ou não usar uma abordagem OO "academicamente elegante", n-camadas ou seja lá o que for, e isso não vai definir se sua arquitetura é boa ou ruim.

    Contanto que você alcance algo que lhe proporcione:

    1-Abstração, ou seja, métodos simples de entender e de dar manutenção

    2-Performance

    3-Facilidade em reutilizar o que já foi escrito

    4-Facilidade em adaptação da sua equipe de desenvolvimento àquele ambiente

    5-Produtividade

     

    Ta bom demais! Pode ser OO? Pode. Pode não ser? Pode também.

     

    Esse seu sentimento de que poderia estar fazendo uma arquitetura mais interessante é ótimo, investigue e veja onde pode chegar. Mas nunca cometa o erro de usar algo só porque todo mundo diz que é bacana. Arquitetura demais é tão ruim quanto arquitetura de menos. Se você decidir mudar algo no que tem funcionado bem pra você, mude somente com boas justificativas na sua realidade.

    Agora, a má notícia é que sempre você vai olhar pra tras e dizer: Eh, dava pra fazer ainda melhor...

    ;)

    Monday, January 22, 2007 8:01 AM
  • olá,

    o pior erro desde de que começou a aguerra ensana por programas windows um montanha começou a desabar. As pessoas deveriam er aprendido a programar em WIN32. Puro e simples. depois disso, naum haveria dúvidas em questão relativas a OO.

     

    vai por mim.

    Tuesday, July 17, 2007 2:45 AM