none
Duvidas Modelagem

    Question

  • Ola Pessoal,

    Estou com uma duvida.

    O modelo que eu estou desenvolvendo é baseado em um sistema comercial.

    Foi solicitado que eu devo implementar as entidades "Funcionario" que contem um "Cargo" tipo auxiliar,repositor etc... esses cargos o usuário pode cadastrar.

    Mas, Existem dois cargos que se diferenciam dos demais, que são: Comprador,Vendedor Porque???

    Para associar "Comprador" com "Pedidos de Compra" e "Vendedor" com "Pedidos de Venda"

    No meu ponto de vista ficaria assim.

                                                ____________                           ______________
                                                 Funcionario        cargo                   Cargo
                                                ____________  <-----------    ______________


                                                ____________                           ______________
                                                 |                 |
                                      __________     __________
                                       Vendedor :      Comprador :
                                      Funcionario      Funcionario
                                        ________        __________
                                                     
                                        ________        __________
                                   

    Desculpem o desenho...

    A minha duvida é como criar todos estes objetos, se utilizo factory, DI se devo colocar IFs que determinam
    qual o cargo do funcionario tipo:


    funcionario = new Funcionario();

    if (cargo.descricao == Vendedor)
       funcionario = new Vendedor();

    if (cargo.descricao == Comprador
      funcionario = new Comprador();


    Com estes pattners de Injecao de Dependencia, as coisas ficaram mais complexas
    de primeira vista.
    Friday, February 26, 2010 5:30 PM

Answers

  • Amigo, estou no mesmo barco que você, sou desenvolvedor antigo e quando aprendi os novos paradigmas, também fiquei assim. O grande problema da arquitetura é que existem N formas de se fazer as coisas, e ninguem pode falar que esta certo ou errado. Muitos defendem o Anemic Model, outros defendem classes ricas e por ai vai. Eu cheguei a uma grande conclusão, lendo bastante sobre XP:  Mantenha as coisas mais simples possivel. Se você esta trabalhando com classes DAO, fazendo o mapeamento na mão e utilizando SP, você não vai ter nenhum problema em pensar que esta trabalhando estruturado. Neste caso é uma simples consulta, se você por exemplo estivesse usando EF, provavelmente iria fazer esta filtragem com LINQ em vez de SP. Tente sempre manter o foco na agilidade do sistema, mantendo sempre suas classes o mais simples possivel, mas sem usar Anemic Model (porque ai sim vc corre um grande risco de começar a trabalhar estruturado). O livro do Eric é realmente muito bom, da uma grande luz na modelagem de sistemas. Mas matenha suas classes coesas, use a boa formula que uma classe só deve ter uma unica função e as coisas permanecerão nos trilhos. E mantenha tudo sempre o mais simples possivel! E eu pensando que era o único que ficava perdido com tudo isso :)

    Abraços.
    Wednesday, March 10, 2010 5:44 PM
  • Beto,

    vou passar minha opiniao, vc vai assimilando e vamos criticando e amadurecendo o modelo.

    Primeiro paradigma: cargos.
    Vc disse que os cargos devem ser cadastrados no sistema, mas que cada cargo tem comportamentos.
    Te pergunto, quando for cadastrado um novo cargo, como vc vai dar a ele esse comportamento, ou definir as especializacoes? Esse novo cargo nao vai te exigir de qq maneira a mexer no sistema?

    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/
    Monday, March 01, 2010 6:21 PM

All replies

  • Ola, Beto.

    Se o funcionario ja é Vendedor ou Comprador, pq ele precisa ter cargo?

    Sobre os itens, acho que essa abstracao pode estar ou no Funcionario com uma interface de itens de venda ou compra, ou ainda na implementacao dos funcionarios em si, pensa nessa ideia e ve se vc acha que faz sentido. Se sim, posso te ajudar a desenhar essa abstracao e vemos juntos se vale a pena factory, di, qq outro pattern, menos if. rsrs
    abs

    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/
    Sunday, February 28, 2010 2:36 AM
  • Ola Gustavo tudo bem,

    primeiramente obrigado por responder!!

    Vamos la,

    sua pergunta: Se o funcionario ja é Vendedor ou Comprador, pq ele precisa ter cargo?

    Este Trata-se do miolo da minha duvida.

    Preciso da classe cargo associado com funcionário porque o usuário necessitaria cadastrar um novo cargo.

    são cargos em comum que possui comportamentos iguais. "só muda o nome do cargo".

    Mas... Os cargos de Vendedor e Comprador devem ser classes que "no meu ponto de vista" devem existir no sistema para que eu possa associar com os pedidos de compra e venda.

    e outra, o vendedor deverá ter uma especialização de gerente de vendas e o comprador de gerente de compras.

    como posso modelar isso?? voce pode me ajudar??
    Monday, March 01, 2010 3:09 PM
  • Beto,

    vou passar minha opiniao, vc vai assimilando e vamos criticando e amadurecendo o modelo.

    Primeiro paradigma: cargos.
    Vc disse que os cargos devem ser cadastrados no sistema, mas que cada cargo tem comportamentos.
    Te pergunto, quando for cadastrado um novo cargo, como vc vai dar a ele esse comportamento, ou definir as especializacoes? Esse novo cargo nao vai te exigir de qq maneira a mexer no sistema?

    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/
    Monday, March 01, 2010 6:21 PM
  • Desculpe Gustavo, acho que me expressei errado em relação ao comportamentos.

    Pense em um sistema comercial onde os funcionários cadastrados podem ser:
    Assistentes,Auxiliares,Caixas etc...

    Devido a tantos cargos, será que tenho que criar uma classe concreta para cada um  que herdará de Funcionario ?  Pois Assistentes, caixas etc... São todos Funcionarios.

    E se o usuário quizer um novo cargo no sistema, terei de obter os fontes para criar uma nova classe para herdar de funcionario ?

    Pensando nisso, ("Não sei se estou certo") decidi criar uma classe Cargo que se associa com Funcionario.
     
                                                ____________                                   ______________
                                                 Funcionario                                       Cargo
                                                ____________   0..* ----------- 1   ______________


                                                ____________                                   ______________

    até ai tudo bem.

    Mas.. Existem Dois cargos que possuem responsabilidades "a mais" que são: Vendedor e Comprador.


    Será que o Vendedor não deveria ser uma classe?? pois deve se associar com a classe Pedido de Venda, para obter resumos de comissões etc?

    O mesmo acontece com o Comprador, que deverá se associar com a classe Pedido de Compra.

    A minha duvida é em como modelar e implementar isto da melhor maneira possível.

    Ou se há outras formas melhores do que está.

    Ou se essa forma está totalmente errada. (risos)

    Abçs.





    Monday, March 01, 2010 8:17 PM
  • Opa, nao sei se a dúvida permanece mas vamos la!

    No funcionario você terá um atributo cargo do tipo cargo, sem problemas. Você terá uma entidade cargo para seus stakeholders fazerem o cadastramento. (A menos que você esteja utilizando DDD, ai este cargo seria um Object Value, mas ai são outros clientes)

    No pedido de venda(ENTIDADE) você terá um atributo chamado vendedor, que será do tipo funcionario. Quando um stakeholder estiver cadastrando um pedido de venda ele vai ter na tela um campo (pode ser combobox, listbox, grid, etc) apenas com os vendedores. Veja que você vai ter um selecionar vendedores no seu sistema.

    Espero que eu tenha sido claro, qualquer dúvida é só entrar em contato.


    Denis.
    Tuesday, March 09, 2010 6:08 PM
  • Ola Obrigado por responder .

    De acordo com o seu modelo, eu não preciso da classes vendedor certo? apenas um atributo na entidade pedido de venda com o Tipo Funcionario exemplo: 

     class PedidoVenda
    {
          public int IDPedidoVenda      {get; set;}
          public Funcionario Vendedor {get; set;}
       
          demais propriedades e metodos...
    }


    Ok, agora para eu carregar somente os vendedores no combobox ou sei la o que, 
    devo verifica se os funcionarios cadastrados são vendedores com base no obj cargo.


    Ficaria mais o menos assim, (Sei como implementar mas vai ficar extenso demais aqui);

    List<Funcionario> Vendedores = new List<Funcionarios>();

    bla bla bla...

    if (funcionario.cargo.descricao == "Vendedor")
    {
       Vendedores.add(funcionario);
    }

    return Vendedores;

    bla bla bla...

    // ou filtra diretamente por consulta sql na base

    Olha desta forma funciona perfeitamente pois consigo Extrair somente os vendedores ou os compradores.
    (È assim que eu estava pensando em desenvolver).

    Mas será que fazendo este tipo de verificação (se for vendedor...) não estou apelando para o modelo extruturado???

       
    Sabe Denis, é até engraçado a situação em que me encontro:

    Eu desenvolvia livremente de uma forma, mas após ler varios artigos sobre boas praticas e diversos padrões
    OO eu acabei num emaranhado de duvidas com relação a modelagem e acabei perdendo o foco.

    Quando Usar ou não usar Herança e substituir por composição?

    Quando Usar o não usar Inversão de Controle com Injeção de Dependencia? Que por sinal é muito interessante mas faz com que eu extraia as novas instancias para a classe chamadora deixando-a mais complexas?

    Será que devo usar o pattern: BLL - VO - DAL, (Me viro muito bem com esse) que por sinal é
    "ENSINADO EM LIVROS" mas dizem que trata-se de um modelo Anemico que Fére os principios de OO??

    "Já li livros em que o Autor se focava no desenvolvimento das tabelas relacionadas do banco de dados para 
     depois, desenvolver as classes sem utilizar uma unica Herança ou associação".

    No meu ponto de vista, aquela pessoa que inicia seu aprendizado em OO (seja na faculdade ou sei la aonde)
    implementando com base em diagramas UML "Já Começa aprendendo Errado" e tendo que adotar as ("Melhores Praticas") no desenvolvimento.

    Devido a tantas abordagens diferentes, a gente acaba "Pensando Demais em encontrar a melhor forma" para desenvolver um modelo. (Que é o meu caso).

    Sei que há muito conteudo impróprio por ai que ensina de maneira errada, o que dificulta o nosso aprendizado.

    Acabei de comprar o livro Domain Driven Design de "Eric Evans" para ver se consigo enxergar uma luz
    que me faça a desenvolver com o mesmo entusiasmo de antes... (Velhos tempos do Cobol).


    Obrigado!







    Tuesday, March 09, 2010 7:32 PM
  • Amigo, estou no mesmo barco que você, sou desenvolvedor antigo e quando aprendi os novos paradigmas, também fiquei assim. O grande problema da arquitetura é que existem N formas de se fazer as coisas, e ninguem pode falar que esta certo ou errado. Muitos defendem o Anemic Model, outros defendem classes ricas e por ai vai. Eu cheguei a uma grande conclusão, lendo bastante sobre XP:  Mantenha as coisas mais simples possivel. Se você esta trabalhando com classes DAO, fazendo o mapeamento na mão e utilizando SP, você não vai ter nenhum problema em pensar que esta trabalhando estruturado. Neste caso é uma simples consulta, se você por exemplo estivesse usando EF, provavelmente iria fazer esta filtragem com LINQ em vez de SP. Tente sempre manter o foco na agilidade do sistema, mantendo sempre suas classes o mais simples possivel, mas sem usar Anemic Model (porque ai sim vc corre um grande risco de começar a trabalhar estruturado). O livro do Eric é realmente muito bom, da uma grande luz na modelagem de sistemas. Mas matenha suas classes coesas, use a boa formula que uma classe só deve ter uma unica função e as coisas permanecerão nos trilhos. E mantenha tudo sempre o mais simples possivel! E eu pensando que era o único que ficava perdido com tudo isso :)

    Abraços.
    Wednesday, March 10, 2010 5:44 PM