DataSets Tipados X Meus Objetos (Entidades)
10/11/2011
0
Salve salve galera, gostaria de discutir umas dúvidas com vocês.
Seguinte, criei um ambiente de desenvolvimento em .NET (C#) com 3 camadas da seguinte forma:
1º Camada - ENT - Entidades, reflexo das tabelas no banco.
2º Camada - DAL - Acesso ao dados (SELECT, INSERT, UPDATE, DELETE...).
3º Camada - BLL - Lógica de negocio.
Só para exemplificar melhor, Minha UI(View) preenche um objeto CLIENTE_ENT e passa pra CLIENTE_BLL que faz as validações e que por sua vez passa para CLIENTE_DAL que insere o cliente no banco.
Até ai blz.
Para pegar um cliente do banco, minha UI(View) pede para CLIENTE_BLL, que por sua vez valida e pede para CLIENTE_DAL que se conecta no banco, preenche um objeto do tipo CLIENTE_ENT e devolve pra CLIENTE_BLL, que por sua vez devolve pra UI(View).
Também funciona que é uma maravilha, mas ai, lendo sobre DataSet Tipado hoje, tava vendo que usando ele eu poderia substituir meus objetos entidades por ele e não usar DataReader, pois uso DataReader para preencher meus objetos(Entidades).
As dúvidas são as seguinte:
Vou ter alguma diferença de performace Usando meus Objetos(Entidades) e DataReader ao invés de usar DataSets?
Seria recomendando usar DataSets ou do meu jeito?
A alguma forma melhor?
Sei que da pra fazer SELECT, INSERT, UPDATE, DELETE usando datasets e dataadpters. Então eu poderia fazer tudo por eles ou também usar só o DateSet como Entidade, so preenchendo ele e depois fazendo na mão as operações.
Lembrando que do meu jeito funciona normal, a única coisa que eu poderia dizer que faço diferente é que quando preciso preencher um DataGridView por exemplo eu tenho um método no meu DAL que devolve um List<CLIENTE_ENT> por exemplo.
Ai pego esse List<CLIENTE_ENT> na minha UI(View) e faço um foreach dela colocando os registros em um DataTable pra depois usar BindingSource no Grid, ou se for um ListView ja adicono direto.
Comentários?
Seguinte, criei um ambiente de desenvolvimento em .NET (C#) com 3 camadas da seguinte forma:
1º Camada - ENT - Entidades, reflexo das tabelas no banco.
2º Camada - DAL - Acesso ao dados (SELECT, INSERT, UPDATE, DELETE...).
3º Camada - BLL - Lógica de negocio.
Só para exemplificar melhor, Minha UI(View) preenche um objeto CLIENTE_ENT e passa pra CLIENTE_BLL que faz as validações e que por sua vez passa para CLIENTE_DAL que insere o cliente no banco.
Até ai blz.
Para pegar um cliente do banco, minha UI(View) pede para CLIENTE_BLL, que por sua vez valida e pede para CLIENTE_DAL que se conecta no banco, preenche um objeto do tipo CLIENTE_ENT e devolve pra CLIENTE_BLL, que por sua vez devolve pra UI(View).
Também funciona que é uma maravilha, mas ai, lendo sobre DataSet Tipado hoje, tava vendo que usando ele eu poderia substituir meus objetos entidades por ele e não usar DataReader, pois uso DataReader para preencher meus objetos(Entidades).
As dúvidas são as seguinte:
Vou ter alguma diferença de performace Usando meus Objetos(Entidades) e DataReader ao invés de usar DataSets?
Seria recomendando usar DataSets ou do meu jeito?
A alguma forma melhor?
Sei que da pra fazer SELECT, INSERT, UPDATE, DELETE usando datasets e dataadpters. Então eu poderia fazer tudo por eles ou também usar só o DateSet como Entidade, so preenchendo ele e depois fazendo na mão as operações.
Lembrando que do meu jeito funciona normal, a única coisa que eu poderia dizer que faço diferente é que quando preciso preencher um DataGridView por exemplo eu tenho um método no meu DAL que devolve um List<CLIENTE_ENT> por exemplo.
Ai pego esse List<CLIENTE_ENT> na minha UI(View) e faço um foreach dela colocando os registros em um DataTable pra depois usar BindingSource no Grid, ou se for um ListView ja adicono direto.
Comentários?
Francisco Gimenez
Curtir tópico
+ 0
Responder
Posts
10/11/2011
Joel Rodrigues
Cara, considere o seguinte:
se for usar datasets tipados, use suas funcionalidades para tudo (insert, update, delete, select). Eu considero que desenvolver suas próprias rotinas para tratar esses datasets seria mei desnecessário.
Em termos de desempenho, sempre que você faz uma consulta aos seus objetos atuais, como você mesmo falou, são feitas várias conversões, laços, etc. Usando o dataset tipado, você já poderá utilizá-lo diretamente como datasource de seus componentes na UI.
Considere ainda, utilizar stored procedures para realizar o CRUD, com isto você faria mais ou menos o que citou (seu próprio tratamento para algumas operações com o banco), só que não nas classes e sim no próprio banco. Você teria total controle sobre seus stored procedures, definindo como um objeto é inserido, alterado e removido do banco, bem como estruturas de busca pré-definidas.
Se você preza bastante pela orientação a objetos e gosta de evitar uso de SQL no código fonte, fica a sugestão para usar LINQ e Entity Framework.
Essa é minha opinião.
Abraço.
se for usar datasets tipados, use suas funcionalidades para tudo (insert, update, delete, select). Eu considero que desenvolver suas próprias rotinas para tratar esses datasets seria mei desnecessário.
Em termos de desempenho, sempre que você faz uma consulta aos seus objetos atuais, como você mesmo falou, são feitas várias conversões, laços, etc. Usando o dataset tipado, você já poderá utilizá-lo diretamente como datasource de seus componentes na UI.
Considere ainda, utilizar stored procedures para realizar o CRUD, com isto você faria mais ou menos o que citou (seu próprio tratamento para algumas operações com o banco), só que não nas classes e sim no próprio banco. Você teria total controle sobre seus stored procedures, definindo como um objeto é inserido, alterado e removido do banco, bem como estruturas de busca pré-definidas.
Se você preza bastante pela orientação a objetos e gosta de evitar uso de SQL no código fonte, fica a sugestão para usar LINQ e Entity Framework.
Essa é minha opinião.
Abraço.
Responder
10/11/2011
Joel Rodrigues
Entity Framework
Recentemente desenvolvi uma aplicação completa maios ou menos nesse estilo que você utilizou. Desenvolvi minhas classes, tratei seus métodos de acesso ao banco, fiz as devidas validações, etc. Achei ótimo, POO é tudo.
Hoje, conheço o Entity Framework e o LINQ. Já estou trabalhando na migração do sistema utilizando essas tecnologias.
Entre outros, os pontos positivos que me fizeram fazer essa escolha foram: a total compatibilidade entre os tipos de dados do BD e das classes; a não necessidade de escrever métodos para realizar o CRUD; a redução (eu diria 100%) do uso de SQL dentro do código; facilidade de manutenção; relacionamento entre as classes (o modelo reflete exatamente o bd); a facilidade no uso de funções do bd (functions e procedures). Aliado a isso você tem a possibilidade de customizar as classes, definindo seus próprios métodos quando necessário.
Na UI, basta criar um DataSource para a tabela desejada e ligar diretamente aos controles visuais.
Recentemente desenvolvi uma aplicação completa maios ou menos nesse estilo que você utilizou. Desenvolvi minhas classes, tratei seus métodos de acesso ao banco, fiz as devidas validações, etc. Achei ótimo, POO é tudo.
Hoje, conheço o Entity Framework e o LINQ. Já estou trabalhando na migração do sistema utilizando essas tecnologias.
Entre outros, os pontos positivos que me fizeram fazer essa escolha foram: a total compatibilidade entre os tipos de dados do BD e das classes; a não necessidade de escrever métodos para realizar o CRUD; a redução (eu diria 100%) do uso de SQL dentro do código; facilidade de manutenção; relacionamento entre as classes (o modelo reflete exatamente o bd); a facilidade no uso de funções do bd (functions e procedures). Aliado a isso você tem a possibilidade de customizar as classes, definindo seus próprios métodos quando necessário.
Na UI, basta criar um DataSource para a tabela desejada e ligar diretamente aos controles visuais.
Responder
17/11/2011
Francisco Gimenez
Bom dia Joel.
Legal, muito obrigado pelos esclarecimentos e desculpe-me pela demora em responder, eu estava viajando.
Bom, pelo que entendi, a diferença seria em não ter que fazer conversões e tal, pois junto com o MVC que faço, eu construí um CRUD, onde ele faz sozinhos os INSERTS, UPDATES e etc.
Mas mesmo assim, vou criar algum protótipo usando Dataset tipados pra ver como fica, vou testar com EF também.
Aproveitando o gancho, tanto com DS Tipado e EF penso em alguns pontos:
- Tenho que trabalhar com N bancos (Oracle, Informix, Sql-Server, Mysql, etc), com o framework que fiz funciona certinho, o CRUD já identifica o banco da conexão e se vira, com EF seria fácil de fazer isso também?
- Às vezes tenho que trabalha com mais de uma conexão simultânea, exemplo, ledo arquivos do MySql e jogando no Oracle, com o EF isso seria fácil e de forma transparente também?
Obrigado.
Legal, muito obrigado pelos esclarecimentos e desculpe-me pela demora em responder, eu estava viajando.
Bom, pelo que entendi, a diferença seria em não ter que fazer conversões e tal, pois junto com o MVC que faço, eu construí um CRUD, onde ele faz sozinhos os INSERTS, UPDATES e etc.
Mas mesmo assim, vou criar algum protótipo usando Dataset tipados pra ver como fica, vou testar com EF também.
Aproveitando o gancho, tanto com DS Tipado e EF penso em alguns pontos:
- Tenho que trabalhar com N bancos (Oracle, Informix, Sql-Server, Mysql, etc), com o framework que fiz funciona certinho, o CRUD já identifica o banco da conexão e se vira, com EF seria fácil de fazer isso também?
- Às vezes tenho que trabalha com mais de uma conexão simultânea, exemplo, ledo arquivos do MySql e jogando no Oracle, com o EF isso seria fácil e de forma transparente também?
Obrigado.
Responder
17/11/2011
Joel Rodrigues
Bem, eu particularmente nunca usei EF com outro banco a não ser MS SQL Server, porém, vi alguns artigos na net sobre essa possibilidade. Dê uma pesquisada no tema que talvez encontre algo.
Quanto a várias conexões, não vejo nenhum problema, bastaria você criar um EDM (Entity Data Model) para cada banco.
Abraço.
Quanto a várias conexões, não vejo nenhum problema, bastaria você criar um EDM (Entity Data Model) para cada banco.
Abraço.
Responder
Clique aqui para fazer login e interagir na Comunidade :)
