none
Aplicação em camadas RRS feed

  • Pergunta

  •  

    Amigos mas um vez venho solicitar ajuda de vcs.

     

    Aqui na empresa estamos desenvolvendo um sistema usando a metodologia em 3 camadas.

    O conceito sobre o assunto esta claro em nossas mentes:

     

    Mas o que gera duvida e a questão de propriedade e informações entre as camadas

    como trafegar as informações entre as camadas ao retornar para o banco de dados?

     

    A clsee de negoc que chama dos metodos do DAL e passa as informações traves das proprety ou tem um outro modo de fazer este trafico de informações

     

    aguadeço desde ja a ajuda de todos

    terça-feira, 31 de julho de 2007 15:40

Respostas

  • Gabriel, creio que seria melhor postar no forum de arquitetura, por esse motivo vou mover essa thread para lá ok?

     

    Bem, normalmente nesse cenário o que trafega são entity objects, ou seja, objetos que mapeam as tabelas ou visão de seu banco de dados ou objetos do ADO.NET (DataTable e DataSet). Sendo a primeira opção, na minha opinião, a melhor e mas mais trabalhosa. Existem diversos frameworks e geradores de código para realizar tal tarefa, te aconselho a dar uma olhada no LINQ (tem um fórum sobre ele aqui na MSDN Brasil).

     

    terça-feira, 31 de julho de 2007 15:52
  • Existe um artigo bem completo no MSDN que fala sobre a camada de dados e também das estratégias possíveis de passagem dos entre as diversas camadas.

    http://msdn2.microsoft.com/en-us/library/ms978496.aspx

     

    Eu concordo com o Leornardo que a melhor opção é trafegar entidades ao invés de objetos ADO.Net, pelos seguintes motivos:

    - Desta forma sua aplicação fica muito mais resistente a possíveis mudanças no ADO.Net

    - Os objetos ADO.Net representam o banco de dados em memória, ou seja seguem o modelo relacional. Sua camada de negócios, por outro lado, deve seguir o modelo de objetos.

     

    Mais detalhes sobre isto no meu blog:

    http://eduardomiranda.net/blogs/dotnet/archive/2007/03/18/isolando-camadas-da-aplica-o.aspx

     

    O único ponto que discordo do Leonardo é que entities são objetos que mapeiam tabelas ou visões do seu BD. Para mim entities são objetos que representam objetos de negócios relevantes para sua aplicação. O seu mapeamento com o Banco de dados é "secundário".

     

    Eduardo Miranda

    http://www.eduardomiranda.net/blogs/dotnet/

     

    terça-feira, 31 de julho de 2007 19:19
  • Obrigado mesmo pela a indicação do materia irei analisar.

    Gostaria de dizer como estou fazendo neste exemplo que venho fazendo e aplicando as camadas tenho 3 classes

    Classe Stick out tongueersistem os dados no banco DAL
    Classe :Com as  variaveis com o escopo privada e as property com get e set
    Classe: E regra de negocio

    quando quero recuperar os dados do banco, atraves das property envio um criterio para o metodo recuperaDataset que executa o commando e preenche o meu datatable e assim tenho meus dados no gridview e da para frente faço a navegação enfim tudo que ja sabemos.

    Para inserir os dados chamo da classe DAL o meu metodo que cria os parametros que chama o metodo que cria os command e atraves o paramArray e grava os dados no meu bando de dados

    Mas antes de enviar os dados da minha camada de apresentação tenho uma classe que monta os parametros atraves dos valores da property como o exemplo abaixo:

    Public Sub parametros(ByVal dados As negocio.ClsProperty)
            Dim obj As New ClsBanco
            Dim param() As FbParameter = { _
            obj.criarParametros("@comando", FbDbType.VarChar, dados.Comando), _
            obj.criarParametros("@id", FbDbType.VarChar, dados.Id), _
            obj.criarParametros("@aberturaag", FbDbType.Integer, dados.AberAtividade), _
            obj.criarParametros("@finalizadoag", FbDbType.Date, dados.FinalAtividade), _
            obj.criarParametros("@elaborado", FbDbType.Char, dados.Elaborado), _
            obj.criarParametros("@atividade", FbDbType.VarChar, dados.Atividade), _
            obj.criarParametros("@dtaatividade", FbDbType.Date, dados.DataEvento), _
            obj.criarParametros("@inihorario", FbDbType.Date, dados.InicioHorario), _
            obj.criarParametros("@terhorario", FbDbType.Date, dados.FinalAtividade), _
            obj.criarParametros("@funcionario", FbDbType.Char, dados.Funcionario), _
            obj.criarParametros("@repetifreq", FbDbType.Char, dados.RepetirFrequencia), _
            obj.criarParametros("repetirdata", FbDbType.Date, dados.Repetirdata), _
            obj.criarParametros("@diasUteis", FbDbType.Char, dados.DiasUteis), _
            obj.criarParametros("@fotos", FbDbType.VarChar, dados.Foto), _
            obj.criarParametros("@tipoatividade", FbDbType.Char, dados.TipoAtividade), _
            obj.criarParametros("@descAtividade", FbDbType.VarChar, dados.descricaoAtividade)}
        End Sub

    Bem espero que vc entenda pois tem horas que fico meio doido com estas coisa ..risos
    Na verdade não sei ate onde isto esta certo a minha preocupação que a camada de negocio não saiba que banco de dados esteja usando

    Mas agradeço desde já

    terça-feira, 31 de julho de 2007 19:50
  • Oi Eduardo, será que o problema é de nomeclatura? Eu vejo entities como tais representaçoes que eu citei e objetos de negócio algo que não trafega e sim valida o meu negócio utilizando os dados contidos nas entities. No Linq to SQL por exemplo, ao criarmos (via design) o arquivo dbml, ele gera uma classe para cada tabela (eu entendo como entidades) e são esses objetos que (ainda estou na luta para ver uma forma de desvencilhar essas classes e coloca-las em outro assembly) irão trafegar. Já no ADO.NET vNext ou Entity Framework temos o EDM, que nos permite criar uma visão de negócio e gerar as classes no formato que você disse, ou seja, negócios. Mas também são chamadas de entities. Tanto que a definição no documento sobre ADO.NET Entity Framework é: Entity: "Richly structured records with a key. Entities are gouped in Entity-Sets".

     

    Espero que não tenha confundido o nosso colega que fez a pergunta. Abraço.

    terça-feira, 31 de julho de 2007 20:00
  •  

    A nomeclatura as vezes pode confundir. Realmente algumas pessoas falam de entidades com o objeto de negócio em si, outras como o DTO (Data Transfer Object) que representa os dados de um objeto de negócio.

     

    Nos dois caso prefiro sempre pensar nas entidades como objetos representativos para o negócio. Lógico que muitas delas vão ter relação um para um com a tabela, mas nem sempre é o caso.

     

    Você pode ter tabelas que não tem importância para o négocio, portanto não deveriam se tornar entidades. Você também pode ter entidades que precisam de mais de uma tabela. Um exemplo: Você vai usar um banco de dados já modelado. Este banco tem a tabela clientes e a tabela informacaoClientes, que se relacionam 1 X 1 (não me pergunte porque, mas eu já vi muito este tipo de modelagem). Na sua aplicação você vai querer apenas uma entidade, a de cliente.

     

    A questão também é por onde você começa sua modelagem, eu prefiro começar da camada de negócios, a partir dai seguir para o BD. Mas quando você está modelando os dois a tendência é que fique praticamente tudo 1 X 1 entre entidades e tabelas. O LINQ to SQL é bem indicado para esta situação, na qual você está criando o banco de dados.

     

    Ainda não olhei o Entity Framework. Eu sei que ele bem mais "parrudo" que o LINQ to SQL, mas como eles estavam revendo algumas decisões de arquitetura, decidi esperar um pouco. O que sei é que as críticas no MVP summit (vc deve saber isto mais do que eu Smile era que as ferramentas eram voltadas para modelagem banco > camada de negócios e não ajudavam muito pelo contrário.

    http://laribee.com/blog/2007/06/04/entity-framework-pi/

     

    Uma técnica muito interessante de modelagem e desenvolvimento é o DDD (Domain Design Driven) que valoriza muito a camada de negócios, para eles ela deve ser isolada do mundo, contendo somente regras de negócios.

    http://domaindrivendesign.org/

    terça-feira, 31 de julho de 2007 20:46

Todas as Respostas

  • Gabriel, creio que seria melhor postar no forum de arquitetura, por esse motivo vou mover essa thread para lá ok?

     

    Bem, normalmente nesse cenário o que trafega são entity objects, ou seja, objetos que mapeam as tabelas ou visão de seu banco de dados ou objetos do ADO.NET (DataTable e DataSet). Sendo a primeira opção, na minha opinião, a melhor e mas mais trabalhosa. Existem diversos frameworks e geradores de código para realizar tal tarefa, te aconselho a dar uma olhada no LINQ (tem um fórum sobre ele aqui na MSDN Brasil).

     

    terça-feira, 31 de julho de 2007 15:52
  • Existe um artigo bem completo no MSDN que fala sobre a camada de dados e também das estratégias possíveis de passagem dos entre as diversas camadas.

    http://msdn2.microsoft.com/en-us/library/ms978496.aspx

     

    Eu concordo com o Leornardo que a melhor opção é trafegar entidades ao invés de objetos ADO.Net, pelos seguintes motivos:

    - Desta forma sua aplicação fica muito mais resistente a possíveis mudanças no ADO.Net

    - Os objetos ADO.Net representam o banco de dados em memória, ou seja seguem o modelo relacional. Sua camada de negócios, por outro lado, deve seguir o modelo de objetos.

     

    Mais detalhes sobre isto no meu blog:

    http://eduardomiranda.net/blogs/dotnet/archive/2007/03/18/isolando-camadas-da-aplica-o.aspx

     

    O único ponto que discordo do Leonardo é que entities são objetos que mapeiam tabelas ou visões do seu BD. Para mim entities são objetos que representam objetos de negócios relevantes para sua aplicação. O seu mapeamento com o Banco de dados é "secundário".

     

    Eduardo Miranda

    http://www.eduardomiranda.net/blogs/dotnet/

     

    terça-feira, 31 de julho de 2007 19:19
  • Obrigado mesmo pela a indicação do materia irei analisar.

    Gostaria de dizer como estou fazendo neste exemplo que venho fazendo e aplicando as camadas tenho 3 classes

    Classe Stick out tongueersistem os dados no banco DAL
    Classe :Com as  variaveis com o escopo privada e as property com get e set
    Classe: E regra de negocio

    quando quero recuperar os dados do banco, atraves das property envio um criterio para o metodo recuperaDataset que executa o commando e preenche o meu datatable e assim tenho meus dados no gridview e da para frente faço a navegação enfim tudo que ja sabemos.

    Para inserir os dados chamo da classe DAL o meu metodo que cria os parametros que chama o metodo que cria os command e atraves o paramArray e grava os dados no meu bando de dados

    Mas antes de enviar os dados da minha camada de apresentação tenho uma classe que monta os parametros atraves dos valores da property como o exemplo abaixo:

    Public Sub parametros(ByVal dados As negocio.ClsProperty)
            Dim obj As New ClsBanco
            Dim param() As FbParameter = { _
            obj.criarParametros("@comando", FbDbType.VarChar, dados.Comando), _
            obj.criarParametros("@id", FbDbType.VarChar, dados.Id), _
            obj.criarParametros("@aberturaag", FbDbType.Integer, dados.AberAtividade), _
            obj.criarParametros("@finalizadoag", FbDbType.Date, dados.FinalAtividade), _
            obj.criarParametros("@elaborado", FbDbType.Char, dados.Elaborado), _
            obj.criarParametros("@atividade", FbDbType.VarChar, dados.Atividade), _
            obj.criarParametros("@dtaatividade", FbDbType.Date, dados.DataEvento), _
            obj.criarParametros("@inihorario", FbDbType.Date, dados.InicioHorario), _
            obj.criarParametros("@terhorario", FbDbType.Date, dados.FinalAtividade), _
            obj.criarParametros("@funcionario", FbDbType.Char, dados.Funcionario), _
            obj.criarParametros("@repetifreq", FbDbType.Char, dados.RepetirFrequencia), _
            obj.criarParametros("repetirdata", FbDbType.Date, dados.Repetirdata), _
            obj.criarParametros("@diasUteis", FbDbType.Char, dados.DiasUteis), _
            obj.criarParametros("@fotos", FbDbType.VarChar, dados.Foto), _
            obj.criarParametros("@tipoatividade", FbDbType.Char, dados.TipoAtividade), _
            obj.criarParametros("@descAtividade", FbDbType.VarChar, dados.descricaoAtividade)}
        End Sub

    Bem espero que vc entenda pois tem horas que fico meio doido com estas coisa ..risos
    Na verdade não sei ate onde isto esta certo a minha preocupação que a camada de negocio não saiba que banco de dados esteja usando

    Mas agradeço desde já

    terça-feira, 31 de julho de 2007 19:50
  • Oi Eduardo, será que o problema é de nomeclatura? Eu vejo entities como tais representaçoes que eu citei e objetos de negócio algo que não trafega e sim valida o meu negócio utilizando os dados contidos nas entities. No Linq to SQL por exemplo, ao criarmos (via design) o arquivo dbml, ele gera uma classe para cada tabela (eu entendo como entidades) e são esses objetos que (ainda estou na luta para ver uma forma de desvencilhar essas classes e coloca-las em outro assembly) irão trafegar. Já no ADO.NET vNext ou Entity Framework temos o EDM, que nos permite criar uma visão de negócio e gerar as classes no formato que você disse, ou seja, negócios. Mas também são chamadas de entities. Tanto que a definição no documento sobre ADO.NET Entity Framework é: Entity: "Richly structured records with a key. Entities are gouped in Entity-Sets".

     

    Espero que não tenha confundido o nosso colega que fez a pergunta. Abraço.

    terça-feira, 31 de julho de 2007 20:00
  •  

    A nomeclatura as vezes pode confundir. Realmente algumas pessoas falam de entidades com o objeto de negócio em si, outras como o DTO (Data Transfer Object) que representa os dados de um objeto de negócio.

     

    Nos dois caso prefiro sempre pensar nas entidades como objetos representativos para o negócio. Lógico que muitas delas vão ter relação um para um com a tabela, mas nem sempre é o caso.

     

    Você pode ter tabelas que não tem importância para o négocio, portanto não deveriam se tornar entidades. Você também pode ter entidades que precisam de mais de uma tabela. Um exemplo: Você vai usar um banco de dados já modelado. Este banco tem a tabela clientes e a tabela informacaoClientes, que se relacionam 1 X 1 (não me pergunte porque, mas eu já vi muito este tipo de modelagem). Na sua aplicação você vai querer apenas uma entidade, a de cliente.

     

    A questão também é por onde você começa sua modelagem, eu prefiro começar da camada de negócios, a partir dai seguir para o BD. Mas quando você está modelando os dois a tendência é que fique praticamente tudo 1 X 1 entre entidades e tabelas. O LINQ to SQL é bem indicado para esta situação, na qual você está criando o banco de dados.

     

    Ainda não olhei o Entity Framework. Eu sei que ele bem mais "parrudo" que o LINQ to SQL, mas como eles estavam revendo algumas decisões de arquitetura, decidi esperar um pouco. O que sei é que as críticas no MVP summit (vc deve saber isto mais do que eu Smile era que as ferramentas eram voltadas para modelagem banco > camada de negócios e não ajudavam muito pelo contrário.

    http://laribee.com/blog/2007/06/04/entity-framework-pi/

     

    Uma técnica muito interessante de modelagem e desenvolvimento é o DDD (Domain Design Driven) que valoriza muito a camada de negócios, para eles ela deve ser isolada do mundo, contendo somente regras de negócios.

    http://domaindrivendesign.org/

    terça-feira, 31 de julho de 2007 20:46