AJUDA SOBRE PROGRAMACAO EM TRES CAMADAS
estou começando um projeto em C# que será em 3 camadas, UIL, BLL e DAL.
Até onde entendi, é da seguinte forma:
UIL - User Interface Layer - Formularios e tudo mais
BLL - Business Logic Layer - Lógica de negócio, validações
DAL - Data Access Layer - Acesso a dados para GRUD
até ai tudo bem, fiz o cadastro de cliente que ficou da seguinte forma
classes:
Models.Clientes
BLL.BLLClientes
DAL.DALClientes
no método gravar preenchi uma instancia da classe Cliente com as informações digitadas na tela
depois executei > BLLClientes.Incluir(objCliente);
que por sua ver faz validações e estando tudo certo, chama o DAL > DALCLientes.Incluir(objCliente)
me corrijam se eu tiver entendido errado.
agora como fica em relação a pequenas consultas e relatórios?
no formulário de venda quando escolho o cliente, ele checa se ta bloqueado ou inativo,
enfim, sempre existe aquelas consultas para pegar um ou mais campos na hora de escolher determinado opção na tela
e tudo mais, isso pode ficar na UIL, ou tem que ser dentro da BLL !??
as consultas sempre to retornando atraves de DataTables.
e essas pequenas consultas tem que ser feitas dentro do DAL!?
eu uso uma conexão compartilhadas entre os formularios e BLLs
de uma classe de conexão que fiz que reconecta caso haja perca de conexão com o servidor.
com isso posso fazer a consulta dentro da proprio BLL, isso ficaria errado, ou toda consulta tem que ser dentro da DAL?
Até onde entendi, é da seguinte forma:
UIL - User Interface Layer - Formularios e tudo mais
BLL - Business Logic Layer - Lógica de negócio, validações
DAL - Data Access Layer - Acesso a dados para GRUD
até ai tudo bem, fiz o cadastro de cliente que ficou da seguinte forma
classes:
Models.Clientes
BLL.BLLClientes
DAL.DALClientes
no método gravar preenchi uma instancia da classe Cliente com as informações digitadas na tela
depois executei > BLLClientes.Incluir(objCliente);
que por sua ver faz validações e estando tudo certo, chama o DAL > DALCLientes.Incluir(objCliente)
me corrijam se eu tiver entendido errado.
agora como fica em relação a pequenas consultas e relatórios?
no formulário de venda quando escolho o cliente, ele checa se ta bloqueado ou inativo,
enfim, sempre existe aquelas consultas para pegar um ou mais campos na hora de escolher determinado opção na tela
e tudo mais, isso pode ficar na UIL, ou tem que ser dentro da BLL !??
as consultas sempre to retornando atraves de DataTables.
e essas pequenas consultas tem que ser feitas dentro do DAL!?
eu uso uma conexão compartilhadas entre os formularios e BLLs
de uma classe de conexão que fiz que reconecta caso haja perca de conexão com o servidor.
com isso posso fazer a consulta dentro da proprio BLL, isso ficaria errado, ou toda consulta tem que ser dentro da DAL?
ALYSSONLIME, blz?
Eu tb já me enrosquei com essas coisas, principalmente pelo fato, que vc não deve fornece mais informações do que o necessário ao funcionamento de cada camada.
Minha sugestão é que vc trabalhe com EntityFramework na camada de DAL e o retorno será um Query.
As informações entre as classes só deverão ser passadas através da Classe modelo (sendo que a Classe modelo só tem os campos e nenhum método).
Isso é completamente contra as regras do desenvolvimento n-Tier (camadas).
DAL - instruções SQL
BLL - validações, calculos, regras de negócio
UI - pura e simplesmente os forms
Detalhe, isso deve funcionar assim UI->BLL->DAL (Ou seja, UI acessa o BLL que acessa o DAL) JAMAIS ao Contrario!! E todos acessam o Modelo
Eu tb já me enrosquei com essas coisas, principalmente pelo fato, que vc não deve fornece mais informações do que o necessário ao funcionamento de cada camada.
Minha sugestão é que vc trabalhe com EntityFramework na camada de DAL e o retorno será um Query.
As informações entre as classes só deverão ser passadas através da Classe modelo (sendo que a Classe modelo só tem os campos e nenhum método).
Citação:com isso posso fazer a consulta dentro da proprio BLL, isso ficaria errado, ou toda consulta tem que ser dentro da DAL?
Isso é completamente contra as regras do desenvolvimento n-Tier (camadas).
DAL - instruções SQL
BLL - validações, calculos, regras de negócio
UI - pura e simplesmente os forms
Detalhe, isso deve funcionar assim UI->BLL->DAL (Ou seja, UI acessa o BLL que acessa o DAL) JAMAIS ao Contrario!! E todos acessam o Modelo
Agora o controle de transações ficaria na DAL no caso?
Tipo, no meu caso, um cliente pode ter vários dependentes e referências. No caso são três tabelas pra manipular dentro de uma transação.
Essa transação tenho que controlar dentro da DAL, já que tudo que for de instrução SQL e Acesso a Dados ser na DAL?
Sendo na DAL ou BLL, eu to mandando apenas o objeto CLIENTE que nele tem como propriedade uma lista de Dependentes e uma lista de Referencia, já que ambos jamais serão alterados separadamente do cliente pois faz parte do mesmo cadastro.
Então ficaria tres classes modelos mas apenas uma BLL e uma DAL?
Tipo, no meu caso, um cliente pode ter vários dependentes e referências. No caso são três tabelas pra manipular dentro de uma transação.
Essa transação tenho que controlar dentro da DAL, já que tudo que for de instrução SQL e Acesso a Dados ser na DAL?
Sendo na DAL ou BLL, eu to mandando apenas o objeto CLIENTE que nele tem como propriedade uma lista de Dependentes e uma lista de Referencia, já que ambos jamais serão alterados separadamente do cliente pois faz parte do mesmo cadastro.
Então ficaria tres classes modelos mas apenas uma BLL e uma DAL?
O DAL deverá conter métodos para Transações
Em BLL vc apenas irá definir as ações. Mas apenas o DAL irá realizar operações com o SGBD
Em BLL vc apenas irá definir as ações. Mas apenas o DAL irá realizar operações com o SGBD
Beleza, então da forma que falei ta ok.
Agora mesmo aquelas pequenas consulta nos formulários tudo tem que ser através da BLL que chama a DAL para retornar a consulta.
Isso implicaria em ter muitas consultas na BLL e DAL cada qual para um tipo de situação.
é pra ser dessa forma?
Agora mesmo aquelas pequenas consulta nos formulários tudo tem que ser através da BLL que chama a DAL para retornar a consulta.
Isso implicaria em ter muitas consultas na BLL e DAL cada qual para um tipo de situação.
é pra ser dessa forma?
Esse é o ponto chato do processo multicamadas.
Use e abuse do LINQ pra filtrar os dados q vc realmente precisa e, por exemplo, não ter que carregar um combobox com todos os dados dos clientes.
Não sei se vc está fazendo isso, mas o ideal num projeto multicamadas é q as camadas DAL e BLL sejam DLL, com isso vc isola os modulos fisicamente.
Use e abuse do LINQ pra filtrar os dados q vc realmente precisa e, por exemplo, não ter que carregar um combobox com todos os dados dos clientes.
Não sei se vc está fazendo isso, mas o ideal num projeto multicamadas é q as camadas DAL e BLL sejam DLL, com isso vc isola os modulos fisicamente.
No meu caso são 5 projetos na solucion.
Tem uma dll com funções padronizadas como validar cpf e coisas do tipo pra eu utilizar sempre que precisar.
Tem a dll da DAL, uma da BLL, o exe da UIL e uma dos MODELS.
Eu desconheço esse LINQ... de repente eu use ele e nem me toque kkkkkkkkkkkkkkkk.
Consultas to retornando como DataTable. Com exceção quando vou consultar o cadastro do cliente, ai sim ele retorna objeto Cliente.
Tem uma dll com funções padronizadas como validar cpf e coisas do tipo pra eu utilizar sempre que precisar.
Tem a dll da DAL, uma da BLL, o exe da UIL e uma dos MODELS.
Eu desconheço esse LINQ... de repente eu use ele e nem me toque kkkkkkkkkkkkkkkk.
Consultas to retornando como DataTable. Com exceção quando vou consultar o cadastro do cliente, ai sim ele retorna objeto Cliente.
Eu tava vendo aqui, o LINQ me ajuda a fazer consulta dentro de uma lista de objetos como se eu tivesse consultando num banco de dados.
Fiz uns testes aqui, mas de qualquer forma eu teria que carregar a listagem para poder navegar nela, consultar, e tarara?
seria isso?
no meu caso tem um pequeno agravante... o sistema irá funcionar online acessando um banco sql que ficará em outro local atraves da internet. Então o número de consulta e a forma das consultas devem ser de preferências leves...
Fiz uns testes aqui, mas de qualquer forma eu teria que carregar a listagem para poder navegar nela, consultar, e tarara?
seria isso?
no meu caso tem um pequeno agravante... o sistema irá funcionar online acessando um banco sql que ficará em outro local atraves da internet. Então o número de consulta e a forma das consultas devem ser de preferências leves...
Então vc está no caminho certo
Sobre retornar um dataTable, eu li em algum lugar que não era o melhor método, mas num sei dizer agora o porque.
Dê uma fuçada nos links abaixo. As video-aulas do André Baltieri são show de bola.
Video Aula - ADO.NET Entity Framework - Criando uma Aplicação N-Tier [Parte 1/13]
http://www.youtube.com/watch?v=KywGXlfdOvs
Sobre o LINQ
http://msdn.microsoft.com/pt-br/library/bb397906.aspx
Macoratti
http://www.macoratti.net/07/12/net_linq.htm
Sobre retornar um dataTable, eu li em algum lugar que não era o melhor método, mas num sei dizer agora o porque.
Dê uma fuçada nos links abaixo. As video-aulas do André Baltieri são show de bola.
Video Aula - ADO.NET Entity Framework - Criando uma Aplicação N-Tier [Parte 1/13]
http://www.youtube.com/watch?v=KywGXlfdOvs
Sobre o LINQ
http://msdn.microsoft.com/pt-br/library/bb397906.aspx
Macoratti
http://www.macoratti.net/07/12/net_linq.htm
só mais uma dúvida.
então toda e qualquer comunicação de dados entre as camadas devem ser somente com classes MODELs?
então toda e qualquer comunicação de dados entre as camadas devem ser somente com classes MODELs?
Pelos conceitos de programação n-Tier, sim vc deve usar as classes modelos para essa troca de informações.
Tópico encerrado , respostas não são mais permitidas