CLASSE DAL. TER UMA OU VARIAS?
Boa tarde,Pessoal!
Pessoal,tenho estou com dúvidas práticas sobre OO:
1.) O que eu havia entendido sobre classes DAL (Acesso a Dados),é que para cada classe
de negócios do diagrama de classes (Por exemplo ClCliente,ClFornecedor,ClFuncionario,etc...)
deve haver sua correspondente classe DAL.Tanto assim,que existem os chamados [Ô]geradores
de classe DAL[Ô],para facilitar o trabalho.No entanto,na internet existem muitos profissionais dando
exemplo de como criar classes DAL, que podem ser usadas de modo genérico.Do ponto de vista
da OO,que correto é que o sistema tenha as classes DAL separadas para cada classe de negócio,
ou pode-se usar uma DAL DAL genérica para várias classes de negócio???
2.) Nos diagramas de classes OO,as classes DAL devem ser exibidas,ou devem ser omitidas?
3.) Ainda dentro de OO,quando minha classe DAL, executa StoredProcedure no SGBD.Se eu partir da
premissa que cada uma das minhas classes de negócio terá suaa classe DAL.O correto é que cada
uma das classes DAL,tenha seu conjunto de StoredProcedure separada no SGBD?
Agradeço qualquer orientação.
Pessoal,tenho estou com dúvidas práticas sobre OO:
1.) O que eu havia entendido sobre classes DAL (Acesso a Dados),é que para cada classe
de negócios do diagrama de classes (Por exemplo ClCliente,ClFornecedor,ClFuncionario,etc...)
deve haver sua correspondente classe DAL.Tanto assim,que existem os chamados [Ô]geradores
de classe DAL[Ô],para facilitar o trabalho.No entanto,na internet existem muitos profissionais dando
exemplo de como criar classes DAL, que podem ser usadas de modo genérico.Do ponto de vista
da OO,que correto é que o sistema tenha as classes DAL separadas para cada classe de negócio,
ou pode-se usar uma DAL DAL genérica para várias classes de negócio???
2.) Nos diagramas de classes OO,as classes DAL devem ser exibidas,ou devem ser omitidas?
3.) Ainda dentro de OO,quando minha classe DAL, executa StoredProcedure no SGBD.Se eu partir da
premissa que cada uma das minhas classes de negócio terá suaa classe DAL.O correto é que cada
uma das classes DAL,tenha seu conjunto de StoredProcedure separada no SGBD?
Agradeço qualquer orientação.
Caro marcos
Tratando-se de OOP os conceitos que ora aplicado a web Form tambem pode ser aplciados para WindowsForm
[Ô]Apenas em CAMADAS de NEGÓCIO e DADOS[Ô]
Já utilizo a muito tempo estas regras para cada Classe de BLL Criada sua respectiva Classe DAL.
Mudamos inclusive para PROJETO BLL | PROJETO DAL | PROJETO UI
e cada projeto dividimos ainda para facilitar o LEGADO desse sistema............
Para manter OOP Herança e todas novas forma e modelos de melores poráticas para faciliar a elaboração, desenvolvimento e a manuteção.
Se depender da complexidade do sistema
Nos casos de Melhores práticas ainda tratamos o código ainda mais particionado
Criamos um CLASSE ENTIDADES (Entity)
Tratamos todos os métodos e propriedades referente as opções em CLASSE de NEGÓCIO
CLASSE NEGÓCIO (BLL)
Todos os construtores de Chamada [ô]CRUD[ô] Inclusão, alteração, exclusão e Consulta da CLASSE DE DADOS
Que por sua vez é utilizada na CLASSE DE DADOS (DAL).
classe c riada para todos os construtores de acesso a dados..........
Ainda melhoramos o nosso código
Criando as Camadas de Shared(Compartilhado) e classe Meta Dados (MetaData)
CLASSE Compartilhada fica nela exprpessas todas as funções que se repete dentro do código
Exemplo: Funçãode Limpar TextBox.Text ou Caluclo do Digito Verificador Modulo 10 e 11
CLASSE METADATA Classe igual a DAL só que trazz apenas os select de estrutura das tabelas
Consultas de Validação e integração de CAMPOS do Banco de Dados com a UI (User Interface).
Realmente estão utilizando isso dessa forma pois trata-se de um conceito antigo. Mas atualmente com a evolução das linguagens e das máquinas como muitos dos sistemas hoje desenvolvido com um alto grau de complexidade realmente é mais fácil trabalhar e aplicar manutenção de estiver todo dividido.
tenho sistemas que estou aplicando já o conceito de 6 camadas. Pela complexidade e evolução das aplicações dividimos inclusive a Interface para facilitar a manutenção e a mudança de tecnologia pois os controles são o ponto chave na mudança de tecnologia...................
Hoje conesguimos mudar de APSX para HTML ou até para Windows Form sem muito transtono e perda do código desenvolvido............................
Dentro da SOLUTION fica destado assim:
Projeto.BLL
Projeto.DAL
Projeto.Entity
Projeto.Shared
Projeto.MetaData
SeuProjeto.UI => User interface (Web, Desktop, Mobile, Tablet)
Aplicando suas regras e as devidas referências..................
Este conceito são aplicados a todos os framework e as todas versões do Visual Studio.
Aparentemente parece complexo mas na hora da manutenção é que se percebe o grau de organização.....................
Códigos organizados.................
Boa sorte
Tratando-se de OOP os conceitos que ora aplicado a web Form tambem pode ser aplciados para WindowsForm
[Ô]Apenas em CAMADAS de NEGÓCIO e DADOS[Ô]
Já utilizo a muito tempo estas regras para cada Classe de BLL Criada sua respectiva Classe DAL.
Mudamos inclusive para PROJETO BLL | PROJETO DAL | PROJETO UI
e cada projeto dividimos ainda para facilitar o LEGADO desse sistema............
Para manter OOP Herança e todas novas forma e modelos de melores poráticas para faciliar a elaboração, desenvolvimento e a manuteção.
Se depender da complexidade do sistema
Nos casos de Melhores práticas ainda tratamos o código ainda mais particionado
Criamos um CLASSE ENTIDADES (Entity)
Tratamos todos os métodos e propriedades referente as opções em CLASSE de NEGÓCIO
CLASSE NEGÓCIO (BLL)
Todos os construtores de Chamada [ô]CRUD[ô] Inclusão, alteração, exclusão e Consulta da CLASSE DE DADOS
Que por sua vez é utilizada na CLASSE DE DADOS (DAL).
classe c riada para todos os construtores de acesso a dados..........
Ainda melhoramos o nosso código
Criando as Camadas de Shared(Compartilhado) e classe Meta Dados (MetaData)
CLASSE Compartilhada fica nela exprpessas todas as funções que se repete dentro do código
Exemplo: Funçãode Limpar TextBox.Text ou Caluclo do Digito Verificador Modulo 10 e 11
CLASSE METADATA Classe igual a DAL só que trazz apenas os select de estrutura das tabelas
Consultas de Validação e integração de CAMPOS do Banco de Dados com a UI (User Interface).
Citação:.No entanto,na internet existem muitos profissionais dando
exemplo de como criar classes DAL, que podem ser usadas de modo genérico
Realmente estão utilizando isso dessa forma pois trata-se de um conceito antigo. Mas atualmente com a evolução das linguagens e das máquinas como muitos dos sistemas hoje desenvolvido com um alto grau de complexidade realmente é mais fácil trabalhar e aplicar manutenção de estiver todo dividido.
tenho sistemas que estou aplicando já o conceito de 6 camadas. Pela complexidade e evolução das aplicações dividimos inclusive a Interface para facilitar a manutenção e a mudança de tecnologia pois os controles são o ponto chave na mudança de tecnologia...................
Hoje conesguimos mudar de APSX para HTML ou até para Windows Form sem muito transtono e perda do código desenvolvido............................
Dentro da SOLUTION fica destado assim:
Projeto.BLL
Projeto.DAL
Projeto.Entity
Projeto.Shared
Projeto.MetaData
SeuProjeto.UI => User interface (Web, Desktop, Mobile, Tablet)
Aplicando suas regras e as devidas referências..................
Este conceito são aplicados a todos os framework e as todas versões do Visual Studio.
Aparentemente parece complexo mas na hora da manutenção é que se percebe o grau de organização.....................
Códigos organizados.................
Boa sorte
AJSO,muito obrigado pelas orientações!
Se entendi corretamente,você enfatizou a importância de manter o projeto bem [Ô]Dividido[Ô],fragmentado mesmo em módulos
funcionais para aumentar o grau de organização e permitir maior facilidade quando for necessário realizar mudanças ou
fazer manutenção.
Quanto as dúvidas pontuais que citei acima,você ou algum colega sabe esclarecer?
Se entendi corretamente,você enfatizou a importância de manter o projeto bem [Ô]Dividido[Ô],fragmentado mesmo em módulos
funcionais para aumentar o grau de organização e permitir maior facilidade quando for necessário realizar mudanças ou
fazer manutenção.
Quanto as dúvidas pontuais que citei acima,você ou algum colega sabe esclarecer?
Citação:2.) Nos diagramas de classes OO,as classes DAL devem ser exibidas,ou devem ser omitidas?
Isso vai da polÃtica de cada um, eu, pessoalmente não uso SE a classe faz somente gravação/leitura, não vejo necessidade. Mas porém se a mesma fizer alguma coisa extra(um log por exemplo), ou se usar uma SP que faz mais alguma coisa, aà eu coloco.
Citação:3.) Ainda dentro de OO,quando minha classe DAL, executa StoredProcedure no SGBD.Se eu partir da
premissa que cada uma das minhas classes de negócio terá suaa classe DAL.O correto é que cada
uma das classes DAL,tenha seu conjunto de StoredProcedure separada no SGBD?
Quanto mais fragmentado, melhor, isso vale para tudo. Imagine como se tudo fossem pecinhas de LEGO, quando menorzinhas elas forem, mais coisas se podem construir. Se tiver peças que já são algo, complica. Imagine que você tem um conjunto de lego e uma das peças é um telhado de uma casinha, as outras são como tijolos. Os tijolos você vai poder aproveitar, o telhadinho é só um telhado mesmo...
Caro MARCOS
Isso mesmo pois mencionei SUAS CLASSE como projeto e não como um classe associada a seu projeto
Pois tem um diferêncial se utilizado junto com a aplicação ou separado como um aplicativo externo (DLL)
Se pegarmos uma classe DAL dentro do projeto terá algumas retrições se cosntruir dessa forma:
Essa Pergunta tem duas respostas
Se CLASSE de seu projeto por conta de uso em memória teria que ser em alguns casos omitida........
Já como um projeto para tornar rápido pode ser exibida e ainda como um método externo a sua camada de interface
public partial class SUACLASSE
{
public static sss.zzz.CLASSEENTITADE GetChamada()
{
//Seu código:
}
}
é ainda mais rápido utilizar assim sem muitos por menores pois quando uma partial class é compilada o compilador agrupa todos os arquivos da classe parcial gerando uma única entidade.
Nessa pergunta
Analisando como Classe
public class NomedaClasso: NAMESPACE DA CLASSE BLL ou ENTIDADE
{
public List<CAMADA BLL OU ENTIDADE> BuscaQualquerCoisa(String codID)
{
//Seu Código
}
}
Nesse caso é para talves pensar em ter ou não problemas caso tenha 100 ou 200 GET SET divididos em CLASSES mesmo assim teria o mesmo acesso a memória......
Se olhar como PROJETO
public partial class TuaClasse
{
public TuaClasse()
{
}
public static List<CAMADA BLL OU ENTIDADE> BuscaQualquerCoisa(String codID)
{
//Seu código
}
}
Isso é só no ganho de performance por Trans formar CLASSES em PROJETOS..................................
Sei que dá um trabalhão analizar dessa forma mas fica mais simples fazer crescer sua aplicação..............................
Não sei se ficou claro mas as resposta como CLASSE ou PROJETO elas mudam completamente o conceito quando se aplica uma enão a outra.............
Não estou dizendo que dessa forma que faz está errado mas se olhar de uma forma um pouco MACRO as situações que podem se transformar em gargalo não ocorerâo.
Exatemente no mesmo conceito a cima como ilustrei.............
Boa Sorte
Isso mesmo pois mencionei SUAS CLASSE como projeto e não como um classe associada a seu projeto
Pois tem um diferêncial se utilizado junto com a aplicação ou separado como um aplicativo externo (DLL)
Se pegarmos uma classe DAL dentro do projeto terá algumas retrições se cosntruir dessa forma:
Essa Pergunta tem duas respostas
Citação:2.) Nos diagramas de classes OO,as classes DAL devem ser exibidas,ou devem ser omitidas?
Se CLASSE de seu projeto por conta de uso em memória teria que ser em alguns casos omitida........
Já como um projeto para tornar rápido pode ser exibida e ainda como um método externo a sua camada de interface
public partial class SUACLASSE
{
public static sss.zzz.CLASSEENTITADE GetChamada()
{
//Seu código:
}
}
é ainda mais rápido utilizar assim sem muitos por menores pois quando uma partial class é compilada o compilador agrupa todos os arquivos da classe parcial gerando uma única entidade.
Nessa pergunta
Citação:3.) Ainda dentro de OO,quando minha classe DAL, executa StoredProcedure no SGBD.Se eu partir da
premissa que cada uma das minhas classes de negócio terá suaa classe DAL.O correto é que cada
uma das classes DAL,tenha seu conjunto de StoredProcedure separada no SGBD?
Analisando como Classe
public class NomedaClasso: NAMESPACE DA CLASSE BLL ou ENTIDADE
{
public List<CAMADA BLL OU ENTIDADE> BuscaQualquerCoisa(String codID)
{
//Seu Código
}
}
Nesse caso é para talves pensar em ter ou não problemas caso tenha 100 ou 200 GET SET divididos em CLASSES mesmo assim teria o mesmo acesso a memória......
Se olhar como PROJETO
public partial class TuaClasse
{
public TuaClasse()
{
}
public static List<CAMADA BLL OU ENTIDADE> BuscaQualquerCoisa(String codID)
{
//Seu código
}
}
Isso é só no ganho de performance por Trans formar CLASSES em PROJETOS..................................
Sei que dá um trabalhão analizar dessa forma mas fica mais simples fazer crescer sua aplicação..............................
Não sei se ficou claro mas as resposta como CLASSE ou PROJETO elas mudam completamente o conceito quando se aplica uma enão a outra.............
Não estou dizendo que dessa forma que faz está errado mas se olhar de uma forma um pouco MACRO as situações que podem se transformar em gargalo não ocorerâo.
Citação:3.) Ainda dentro de OO,quando minha classe DAL, executa StoredProcedure no SGBD.Se eu partir da
premissa que cada uma das minhas classes de negócio terá suaa classe DAL.O correto é que cada
uma das classes DAL,tenha seu conjunto de StoredProcedure separada no SGBD?
Exatemente no mesmo conceito a cima como ilustrei.............
Boa Sorte
Muito obrigado pelos esclarecimentos!
Tópico encerrado , respostas não são mais permitidas