none
Modelo de camadas RRS feed

  • Pergunta

  • Olá gostaria de saber o que vocês acham deste modelo de camadas.

    Onde eu coloco as propriedades e atributos eu chamo de Model

    Exemplo : Historico Model

    protected int _id;
    protected string _historico;
    protected int _matriculaInclusao;
    protected DateTime _dataInclusao;
    protected bool _status;

    Em seguida crio a DAO

    Um exemplo de método na DAO

    public static void Update(CONTRATACAOHISTORICO objCONTRATACAOHISTORICO, DbTransaction transaction, Database db)
    {
    using (DbCommand dbCommand = db.GetStoredProcCommand(PROC_UPDATE))
    {
    
    db.AddInParameter(dbCommand,"@IdHistorico",DbType.Int32,objCONTRATACAOHISTORICO.Id);
    db.AddInParameter(dbCommand,
    
    
    "@Historico",DbType.AnsiString,objCONTRATACAOHISTORICO.Historico); 
    db.AddInParameter(dbCommand,
    
    
    "@MatriculaInclusao",DbType.Int32,objCONTRATACAOHISTORICO.MatriculaInclusao); 
    db.AddInParameter(dbCommand,
    
    
    "@DataInclusao",DbType.DateTime,objCONTRATACAOHISTORICO.DataInclusao); 
    db.AddInParameter(dbCommand,
    
    
    "@Status",DbType.Boolean,objCONTRATACAOHISTORICO.Status); 
     
    
    db.ExecuteNonQuery(dbCommand, transaction);
    
    }
    
    }
    


    E na camada BLL eu chamo este método.

    public static void Update(CONTRATACAOHISTORICO objCONTRATACAOHISTORICO)
    {
    
    
    
    Database db = DatabaseFactory.CreateDatabase("PostOne.Site");
    
    using (DbConnection connection = db.CreateConnection())
    {
    
    connection.Open();
    
    
    
    DbTransaction transaction = connection.BeginTransaction();
    
    
    try
    
    {
    
    ValidateUpdate(objCONTRATACAOHISTORICO, transaction, db);
    
     
    
    
    CONTRATACAOHISTORICODAO.Update(objCONTRATACAOHISTORICO, transaction, db);
    transaction.Commit();
    
    }
    
    
    
    catch 
    { 
    
    transaction.Rollback();
    
    
    
    throw;
    } 
    
    
    
    finally
    
    {
    
    connection.Close();
    
    }
    
    }
    
    }

    Na camada de apresentação eu eu chamo o método da BLL criando os objetos e passando os valores.

    É um boa o que fiz?

    Obrigado.

    Eduardo.

     

    quinta-feira, 10 de setembro de 2009 18:51

Respostas

  • Cara, a forma que você trabalha funciona, como já comentado em outros posts cada caso é um caso.

    A primeira coisa que deve ser pelo menos refletida é:
    "Por que colocamos a regra de negócio em uma classe diferente da entidade de negócio?"

    Vou citar o ja "batido" exemplo do veiculo. Você teria uma classe Veiculo que teria seus atributos e propriedades e possivelmente um metodo chamado "andar", certo? Agora se pegarmos esse mesmo exemplo e aplicarmos na arquitetura que você sugeriu, teríamos um classe Veiculo com os mesmos atributos e propriedades mas teríamos uma classe chamada BLVeiculo que teria o método andar recebendo Veiculo como parametro (Ex.: BLVeiculo.andar(Veiculo carro)). Meio estranho não?

    Quando se trabalha dessa forma (BL, VO (ou Model) e DL) perdemos um potencial muito grande do POO. Já tentou usar herança com esse tipo de desenho arquitetural por exemplo? Se já, imagino que deve ter passado por alguns problemas...

    Existem várias formas de se chegar ao mesmo resultado, como exemplo, tenho certeza que da forma com que você trabalha hoje funciona. A questão é, estar disposto a aprender outras soluções e saber aplicar a melhor solução para o seu problema.

    Eu recomendo você dar uma olhada sobre DDD (Domain Driven Design) se possível ler o livro do Eric Evans sobre o assunto, se você deseja rever sua forma de modelagem ta aí uma boa fonte para você começar a estudar.

    Com certeza é muito polêmico dizer se o que você esta fazendo é certo ou errado, mas com certeza existe outras alternativas que podem ser implementadas para se chegar ao mesmo resultado.


    Eduardo Silva
    http://eduardodotnet.blogspot.com
    quinta-feira, 10 de setembro de 2009 22:40
  • Oi Eduardo,

    Vamos tratar de responsabilidades. Qual a responsabilidade da sua Business Logic Layer (BLL)? Dica: está em negrito.
    Não faz sentido que uma classe na sua camada de negócio abra conexão com banco de dados, e gerencie uma transação do banco de dados. Além disso, a transação sequer é necessária, já que só uma operação de BD acontece. É um típico exemplo de YAGNI.
    Nesse cenário, sua camada de negócios não faz nada, é código que devia estar na camada de acesso a dados. É lá que as responsabilidades de acesso a dados devem estar. Eu eliminaria por completo a classe de BLL, e colocaria a tarefa de abertura de conexão na camada de acesso a dados. A BLL está só encaminhando a chamada, não faz mais nada... Você não precisa criar uma classe de BLL nesse cenário.
    Giovanni Bassi, Microsoft MVP, MCSD, MCPD, CSM, Arquiteto de software - http://www.giovannibassi.com
    sexta-feira, 11 de setembro de 2009 03:46
    Moderador

Todas as Respostas

  • Cara, a forma que você trabalha funciona, como já comentado em outros posts cada caso é um caso.

    A primeira coisa que deve ser pelo menos refletida é:
    "Por que colocamos a regra de negócio em uma classe diferente da entidade de negócio?"

    Vou citar o ja "batido" exemplo do veiculo. Você teria uma classe Veiculo que teria seus atributos e propriedades e possivelmente um metodo chamado "andar", certo? Agora se pegarmos esse mesmo exemplo e aplicarmos na arquitetura que você sugeriu, teríamos um classe Veiculo com os mesmos atributos e propriedades mas teríamos uma classe chamada BLVeiculo que teria o método andar recebendo Veiculo como parametro (Ex.: BLVeiculo.andar(Veiculo carro)). Meio estranho não?

    Quando se trabalha dessa forma (BL, VO (ou Model) e DL) perdemos um potencial muito grande do POO. Já tentou usar herança com esse tipo de desenho arquitetural por exemplo? Se já, imagino que deve ter passado por alguns problemas...

    Existem várias formas de se chegar ao mesmo resultado, como exemplo, tenho certeza que da forma com que você trabalha hoje funciona. A questão é, estar disposto a aprender outras soluções e saber aplicar a melhor solução para o seu problema.

    Eu recomendo você dar uma olhada sobre DDD (Domain Driven Design) se possível ler o livro do Eric Evans sobre o assunto, se você deseja rever sua forma de modelagem ta aí uma boa fonte para você começar a estudar.

    Com certeza é muito polêmico dizer se o que você esta fazendo é certo ou errado, mas com certeza existe outras alternativas que podem ser implementadas para se chegar ao mesmo resultado.


    Eduardo Silva
    http://eduardodotnet.blogspot.com
    quinta-feira, 10 de setembro de 2009 22:40
  • Oi Eduardo,

    Vamos tratar de responsabilidades. Qual a responsabilidade da sua Business Logic Layer (BLL)? Dica: está em negrito.
    Não faz sentido que uma classe na sua camada de negócio abra conexão com banco de dados, e gerencie uma transação do banco de dados. Além disso, a transação sequer é necessária, já que só uma operação de BD acontece. É um típico exemplo de YAGNI.
    Nesse cenário, sua camada de negócios não faz nada, é código que devia estar na camada de acesso a dados. É lá que as responsabilidades de acesso a dados devem estar. Eu eliminaria por completo a classe de BLL, e colocaria a tarefa de abertura de conexão na camada de acesso a dados. A BLL está só encaminhando a chamada, não faz mais nada... Você não precisa criar uma classe de BLL nesse cenário.
    Giovanni Bassi, Microsoft MVP, MCSD, MCPD, CSM, Arquiteto de software - http://www.giovannibassi.com
    sexta-feira, 11 de setembro de 2009 03:46
    Moderador