none
Minha Arquitetura está correta? RRS feed

  • Pergunta

  • Bom dia Galera!

    Fiz o curso S2B(Student to Business) da microsoft ano passado e consegui informações suficientes para fazer bons projetos, pelo menos até agora estou tendo sucesso! Porém não sei se a arquitetura que eles ensinaram está correta, gostaria de discutir isso com vocês!

    É o seguinte, vamos imaginar que eu tenho um formulario de cadastro e quero preencher e salvar em um banco de dados.
    Então a primeira coisa a fazer após chamar o evento click do botão "salvar" é carregar em um HashTable as informações dos TextBox, isso na camada de interface com o usuário, em seguida eu chamo um método na camada de Negócios(BUS) que pega esses valores do HashTable e "seta" na camada de Dados(DAL) esses valores, com isso eu tenho esses valores armazenados(e encapsulados) na camada de Dados(DAL).
    Caso não tenha um segundo formulário para preencher e o objetivo já seria inserir as informações em um banco de dados, a camada de interface chama um método na camada de negócios(BUS) que por sua vez acessa a camada de dados(DAL) para carregar os valores que nela estão armazenados. Em seguida, a camada de negócios(BUS) agora com os valores, faz o procedimento para inserir essas informações no banco de dados. Por fim, a camada de negócios(BUS) retorna um valor para a camada de interface informando se conseguiu inserir com sucesso ou não os dados.

    Então ficou assim:
    Camada de interface que encherga a BUS que encherga a DAL

    Essa arquitetura de camadas está legal? existem formas melhores? Alguma dica do que eu poderia estudar pra ter uma solução melhor para esse caso?

    Agradeço desde já e parabenizo o fórum e seus moderadores pela riqueza de informações!
    sexta-feira, 18 de setembro de 2009 14:14

Respostas

  • Rafael,

    A idéia "central" da coisa foi passada pra você. O que você quer quando trabalha com uma arquitetura em camadas é justamente poder reusar a camada de negócio.

    Suponha-se que invés de uma interface web, você usaria uma UI em Windows Forms. Se a resposta for "sim, eu consigo reaproveitar o código", a arquitetura atingiu um dos seus principais objetivos. O mesmo aplica-se à camada de acesso a dados. Eu consigo "trocá-la" de uma forma relativamente indolor?

    Na abordagem que te apresentaram o principal probelma do meu potno de vista está nas entidades "compostas". Suponhamos que você tenha que cadastrar um pedido com "n" itens. Passar esses valores por um HashTable não vai ser possível... ou não ficará tão intuitivo.

    Por isso, sugiro que estude outras abordagens de arquitetura. Tem uma série de outras propostas, com seus respectivos custos e benefícios (extremamente subjetivos de pessoa para pessoa).

    Eu particularmente gosto da abordagem que usei para este exemplo: http://ericlemes.wikidot.com/dotnet-spring-pt1 (O exemplo não fala de arquitetura, e sim de Spring.Net, mas dá pra ter uma idéia). Eu gosto por causa da facilidade de aplicar dependency injection e AOP (aspect-oriented programming). Tem quem não goste, principalmente por causa da separação entre dados (VO's) e regra de negócio.

    Outra abordagem é Domain Driven Design. Muito interessante também, mas não encontrei muitos exemplos "práticos" por aqui. Pretendo elaborar um, mas não ficará pronto tão logo.


    Abraço,

    Eric
    sexta-feira, 18 de setembro de 2009 16:20

Todas as Respostas

  • A linha entre o certo e o errado é bastante tênue quando falamos de arquitetura de software ;D

    De qualquer forma você poderia pesquisar sobre o que já existe nos fóruns.
    Este tipo de pergunta se repete de 10 em 10 dias.

    Apenas para não ficar em branco, eu particularmente não gosto desta arquitetura.
    Gosto de outras alternativas que já foram discutidas neste fórum.
    []'s
    Rafael Noronha
    http://rafanoronha.net/
    @rafanoronha
    sexta-feira, 18 de setembro de 2009 15:12
  • Rafael,

    A idéia "central" da coisa foi passada pra você. O que você quer quando trabalha com uma arquitetura em camadas é justamente poder reusar a camada de negócio.

    Suponha-se que invés de uma interface web, você usaria uma UI em Windows Forms. Se a resposta for "sim, eu consigo reaproveitar o código", a arquitetura atingiu um dos seus principais objetivos. O mesmo aplica-se à camada de acesso a dados. Eu consigo "trocá-la" de uma forma relativamente indolor?

    Na abordagem que te apresentaram o principal probelma do meu potno de vista está nas entidades "compostas". Suponhamos que você tenha que cadastrar um pedido com "n" itens. Passar esses valores por um HashTable não vai ser possível... ou não ficará tão intuitivo.

    Por isso, sugiro que estude outras abordagens de arquitetura. Tem uma série de outras propostas, com seus respectivos custos e benefícios (extremamente subjetivos de pessoa para pessoa).

    Eu particularmente gosto da abordagem que usei para este exemplo: http://ericlemes.wikidot.com/dotnet-spring-pt1 (O exemplo não fala de arquitetura, e sim de Spring.Net, mas dá pra ter uma idéia). Eu gosto por causa da facilidade de aplicar dependency injection e AOP (aspect-oriented programming). Tem quem não goste, principalmente por causa da separação entre dados (VO's) e regra de negócio.

    Outra abordagem é Domain Driven Design. Muito interessante também, mas não encontrei muitos exemplos "práticos" por aqui. Pretendo elaborar um, mas não ficará pronto tão logo.


    Abraço,

    Eric
    sexta-feira, 18 de setembro de 2009 16:20
  • Valeu Eric,

    Essa questão de trocar a interface web por uma UI em WF me fez parar pra pensar, muito interessante. Realmente encontrei dificuldades na hora de jogar itens na DAL, tive que resolver isso com ArrayList (acho que por essas e outras ando pecando um pouco no meu código).

    Em relação ao DDD, descobri esse assunto a uns 3 dias, foi por ele que vim parar nesse fórum. Só que realmente não encontrei nenhum exemplo prático desse conceito. Pode ter certeza que quando voce postar um aqui vai fazer muito sucesso!

    Abraços,

    Rafa.
    sexta-feira, 18 de setembro de 2009 17:57
  • Rafael,

    Na verdade apesar das das controvérsias, o exemplo que eu citei utilizando dados separados de comportamento, vulgarmente chamado de modelo "anêmico", tem me atendido totalmente nas minhas necessidades.

    Mesmo assim, vale a pena aprender e entender os conceitos de DDD (eu mesmo estou estudando e me aprimorando), já que é a "bola da vez". Quando você começar a estudar arquitetura, vai perceber que a cada 2 anos, inventam um termo novo para representar uma idéia que já existe a algum tempo. Alguns CIO's sem conhecimento técnico muito aprofundado compram a idéia e acabam "impondo" um dado design, mesmo sem conhecer profundamente para poder opinar.

    A idéia central de separação em camadas sempre vai estar em encapsulamento e reuso da camada de negócios. É onde vai estar o maior ganho. Por isso, fazendo essas perguntas como "eu consigo trocar a UI e reusar o código"? vc chega em bons resultados.

    Nessa arquitetura que eu citei, por exemplo, eu consigo reusar toda a regra de negócio e acesso a dados (com as regras na camada certa!) dos seguintes pontos:

    1) UI em WebForms
    2) UI em MVC (em desenvolvimento)
    3) UI em Adobe Flex (usando Web Orb como gateway)
    4) Windows Services que executam operações assíncronas
    5) WebServices publicados usando Spring.Net

    Isso em produção, com alto volume transacional.


    Abraço,

    Eric
    sexta-feira, 18 de setembro de 2009 19:52
  • Depende. (Resposta padrão do arquiteto)
    Quais são os requisitos da aplicação?

    Não há uma arquitetura correta.

    Uma coisa é certa: esse tipo de aplicação é procedural, não é OO. Isso traz diversas implicações. Avalie se o paradigma escolhido está correto, e decida ou não mudar.

    Em tempo: prefiro trabalhar OO.
    Giovanni Bassi, Microsoft MVP, MCSD, MCPD, CSM, Arquiteto de software - http://www.giovannibassi.com
    sábado, 19 de setembro de 2009 05:19
    Moderador
  • Eric,

    DDD não é a bola da vez. O Evans só compilou algo que se fazia a muitos anos. Além disso, o termo existe a 5 anos. O problema é que só chegou no Brasil na comunidade de .Net, com força, recentemente. Na comunidade de Java chegou um pouco antes, mas não muito.

    DDD reune diversas boas práticas. Em grande parte, trata muito de bom senso. Na minha opinião, se DDD é a bola da vez, vai então ser a bola da vez por mais algumas décadas, já que está ligado a técnicas e padrões reconhecidos, como OO, padrão repository, agilidade, etc.
    Giovanni Bassi, Microsoft MVP, MCSD, MCPD, CSM, Arquiteto de software - http://www.giovannibassi.com
    sábado, 19 de setembro de 2009 05:22
    Moderador
  • Giovanni,

    Quando eu digo a "bola da vez" quero dizer justamente isso... que é a mesma idéia apresentada de uma forma diferente, como tantas outras na área de TI. Em momento nenhum afirmo que a abordagem é ruim, pelo contrário, eu gosto dela e com certeza vou me apronfudar mais no assunto para descobrir outros ganhos. Eu mesmo fazia coisa bastante parecida em 2004, ainda em Delphi (dados junto com comportamento) ainda e tive ganhos muito bons, assim como outros problemas tbém.

    Um exemplo de outra bola da vez: SOA. O mundo compra e vende algumas enterprise service bus e obriga tudo a passar por elas. Faz tudo usando web services (que já existem a pelo menos uma década) e vendem como SOA. Ninguém está pensando em rearquitetar suas aplicações para trabalhar como serviços... apenas em inserir mais uma sigla no curriculum.

    Acho que existem outras abordagens de arquitetura que não podem ser totalmente descartadas. Como nós dois afirmamos, não há arquitetura correta. Depende da aplicação e dos ganhos que queremos obter.

    Se formos levar ao pé da letra que se quando separamos dados do comportamento não estamos programando orientado a objeto, então automaticamente afirmaremos que qualquer sistema desenvolvido usando classes em VB6, são sistemas orientados a objetos, mesmo estes não fazendo nenhum uso de abstração, herança e polimorfismo que são outros pilares da OO. Por isso que eu sempre busco não tomar opiniões radicais e sempre foco no uso prático das arquiteturas e patterns. Com a mesma velocidade que um dado padrão se populariza, outro vem e toma o lugar dele (mesmo tendo a mesma idéia central).

    Quando eu comecei a trabalhar com essa separação, inicialmente torci muito o nariz, justamente por ter uma posição radical. Uma série de dúvidas e questionamentos apareceram, principalmente na parte de abstração, como usar strategy (que eu adoro) atrelado ao negócio e fiquei com um certo receio. Á medida que outros benefícios começaram a aparecer, minha opinião aos poucos foi mudando. 

    Agora tenho visto um outro pattern proposto baseado em Spring com UI + Application (Services) + Domain + Data Access... parece interessante, usando DTO (data transfer objects) para passar os dados de UI para application e depois para os "rich object domains". Parece interessante, mais ainda preciso conhecer melhor para formar uma opinião. Parece haver bastante redundância nesta idéia.


    Abraço,

    Eric

    sábado, 19 de setembro de 2009 12:19
  • A definição do que é obrigatório estar presente para que possamos dizer que é orientado a objetos é bastante discutida, mas há alguns consensos. Herança, por exemplo, é entendido como obrigatório, e o VB6 não tinha isso. Juntar dados e comportamento é algo que você pode fazer em sistemas não OO, fazer isso não significa que você está trabalhando OO.

    Colocando lenha na fogueira: tem gente que diz que o C# não é OO porque não tem herança multipla, o que é, na minha opinião um absurdo. E há outros que dizem que o VB6 é OO porque tem herança de interfaces, o que eu também não concordo, porque não tem herança de implementação. Ou seja, a discussão é longa...
    Giovanni Bassi, Microsoft MVP, MCSD, MCPD, CSM, Arquiteto de software - http://www.giovannibassi.com
    segunda-feira, 21 de setembro de 2009 15:50
    Moderador
  • Bacana,

    Pelo menos num consenso nos chegamos. ;-)

    Por isso que eu nunca gosto de levar ao pé da letra as coisas... toda definição é "discutível" e de tempos em tempos aparecem novas idéias e argumentos que tornam algumas idéias "óbvias" não tão óbvias assim...

    Concordo com vc em relação à herança múltipla (nunca me fez falta na vida, somente em Delphi por deficiencia no conceito de interfaces dele a 5 anos atrás) e também concordo em relação a VB6. Pra mim não é orientado a objeto se não tem herança.

    Independente disso, pretendo preparar um exemplo básico de arquitetura em cima de DDD com DI e AOP (vi a aplicação que você mandou, mas ainda não tive tempo de analisar em detalhes). Se vc topar, validamos juntos, apenas para ter uma base de discussão e ajudar os colegas do forum a compreenderem melhor os conceitos.

    Acho que podemos transformar essa discussão e a nossa divergência em algumas opiniões como uma coisa muito produtiva para a comunidade. E é para isso que estamos aqui, né?

    Dei uma boa lida no livro do Evans (excelente do ponto de vista de modelagem), vi um pouco do guia de arquitetura novo da Microsoft e tem muita coisa bacana nessas duas leituras, mas nenhuma delas propõe um exemplo "passo a passo" de implementação... acho que trabalhar nisso daria uma boa visão prática da coisa.


    Abraço,

    Eric

    segunda-feira, 21 de setembro de 2009 17:03