none
Trabalhar em camadas? RRS feed

  • Pergunta

  • Caros colegas. Antes de mais nada sou adepto da ADO.NET ainda. Porém... 

    Com o uso do Entity Framework, para desenvolver um sistema de porte pequeno/médio poderia utilizar apenas duas camadas?

    Uma com o contexto e outra com a interface, sem camada de negócio? Assim consigo atender no prazo por economizar em código.

    A aplicação não tem expectativa de crescimento. Além da desvantagem de uma manutenção mais simples e organizada, uma documentação e regras melhor definidas. Existe alguma desvantagem significativa na não utilização desta camada? Enfim, existe algum cenário onde seja vantagem utilizar duas camadas?

    Obrigado.

    quarta-feira, 7 de janeiro de 2015 12:12

Respostas

  • Olá Leandro,

     você pode deixar suas Entidades visiveis em todas as camadas, assim ao invés de passar propriedade por propriedade na camada UI voce iria passar sua entidade por exemplo :

    clas.X.AdicionarRegistro(Entidade entidade)
    .....

     Somente os metodos da DAL devem ser vistos somente no BLL, mas as entidades pode deixar visivel no projeto todo.

    quarta-feira, 7 de janeiro de 2015 13:27
  • Olá Leandro,

     seria mais ou menos isso... rs 

     veja esse artigo Desenvolvimento em 3 camadas !

     Como não mencionei ainda, há ainda um outro projeto ou seja outra camada chamada Modelo ou Model geralmente nessa camada fica todas suas classes de Entidades e essa sim é vista por todo o projeto justamente para ficar mais facil o transporte de dados, pois antigamente usava parametros para cada tabela, mas ficava enorme os métodos.

      Então ficaria :

     Model = visto por todos( Com suas classes de Entidades)

     DAO = chamado por BLL

    BLL = chamdo por UI

     Lembrando que cada desenvolvedor utiliza de uma maneira não que essa maneira seja a melhor, mas é uma maneira facil de fazer manutenção...

    quarta-feira, 7 de janeiro de 2015 19:05

Todas as Respostas

  • Olá Leandro,

     nada impede de fazer isso mas onde faria as regras de negócio na UI ? a vantagem de se trabalhar com a camada de negocios é que toda chamada a camada de persistencia os dados já estariam correto e essa camada teria o trabalho de apenas persistir dados... Mas nada impede de utilizar uma camada duas, tres... Vejo a vantagem de utilizar tres camada para manutencao, ao utilizar duas como mencionou nao vejo tanta vantagem pois em algum lugar vai ter a necessidade de validar os dados e as regras de negocio, mas se for um projeto pequeno que seria impossivel crescer, mas mesmo assim eu faria outra camada de negocios somente para validacao das regras pois isso levaria poucas horas a mais pois somente cria uma dll e adiciona a referencia assim tem mais controle para tratar erros. 

    quarta-feira, 7 de janeiro de 2015 12:25
  • Meu ponto de vista, a vantagem em utilizar 2 camadas sem a "BusinessLayer" é que vc teria uma requisição a menos (As requisições seria bem mais rápidas por estar cortando caminho) mas isso seria percebido em processamento em grande escala.

    A desvantagem vc mesmo já sacou, que seria uma falta de organização além de matar um pouco o conceito de O.O e que na camada DataAccess ou Core pode haver riscos de ter que rescrever métodos dando duplicidade na hora de codificar.

    Essas desvantagens é percebido ao longo da codificação, este é o meu ponto de vista.

    Abraço.


    Nome : Romy G. Moura Cargo: Analista Programador

    quarta-feira, 7 de janeiro de 2015 12:30
  • Muito obrigado Daniel pela opinião. Vou estudar mais à respeito.
    quarta-feira, 7 de janeiro de 2015 12:34
  • Muito Obrigado Romy pela colaboração. Uma pergunta a você ou Daniel. Sou iniciante ainda com EF na camada DAL deixo apenas o Contexto, na camada BLL consigo acessar a DAL por referência chamando o contexto e tendo acesso as suas entidades. Porém, na camada BLL, teria que criar propriedades para representar as entidades na camada UI?

    Por exemplo: bem simplificada para melhor interpretação.

     ==== Camada de Negócios: ====

    imports DAL

    Public Class cls_X

    property _nome as string, property _sobrenome as string

    public sub AdicionarRegistro(Nome as string, Sobrenome as string)

    using db as new Context.....

    .......

    end sub

    === Interface ===

    imports BLL

    ....

    dim obj as new cls_X

    cls_X.AdicionarRegistro(me.txt1.text, me.txt2.text)

    ......


     
    quarta-feira, 7 de janeiro de 2015 12:52
  • Olá Leandro,

     você pode deixar suas Entidades visiveis em todas as camadas, assim ao invés de passar propriedade por propriedade na camada UI voce iria passar sua entidade por exemplo :

    clas.X.AdicionarRegistro(Entidade entidade)
    .....

     Somente os metodos da DAL devem ser vistos somente no BLL, mas as entidades pode deixar visivel no projeto todo.

    quarta-feira, 7 de janeiro de 2015 13:27
  • Daniel, então eu importaria o DAL na camada UI para poder utilizar suas entidadespodem ao invés de utilizar um método da DAL eu chamaria um método da BLL? Você teria um exemplo que seja em algum site com este modelo?


    quarta-feira, 7 de janeiro de 2015 18:20
  • Olá Leandro,

     seria mais ou menos isso... rs 

     veja esse artigo Desenvolvimento em 3 camadas !

     Como não mencionei ainda, há ainda um outro projeto ou seja outra camada chamada Modelo ou Model geralmente nessa camada fica todas suas classes de Entidades e essa sim é vista por todo o projeto justamente para ficar mais facil o transporte de dados, pois antigamente usava parametros para cada tabela, mas ficava enorme os métodos.

      Então ficaria :

     Model = visto por todos( Com suas classes de Entidades)

     DAO = chamado por BLL

    BLL = chamdo por UI

     Lembrando que cada desenvolvedor utiliza de uma maneira não que essa maneira seja a melhor, mas é uma maneira facil de fazer manutenção...

    quarta-feira, 7 de janeiro de 2015 19:05