Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Fala Galera, beleza?
Alguém teria um exemplo de uma aplicação MVC que tem conexão com banco de dados e realiza as operações CRUD sem utilizar o Entity, na internet só temos exemplo de MVC com Entity!
Como realizar a persistência de dados sem utilizar o EF? Ficaria no Model mesmo? Uma classe por exemplo ClienteMOD e outra ClienteDAO ou ClienteDB(exemplo apenas)?
Com o banco de dados que tenho não rola o Entity...Qualquer ajuda será bem vinda!!
Valeu...Abraço!
Com certeza o melhor é usar o um Entity Framework(EF), pois ele é um mapeador objeto relacional que gera objetos de negócios e entidades de acordo com as tabelas de banco de dados, fornecendo as operações básicas CRUD, o gerenciamento das relações entre as entidades com a capacidade de ter um relacionamento de herança entre entidades. Usando EF, você interage com um modelo e não com o banco de dados relacional. Essa abstração permite que nos concentremos nas regras de negócio e nas relações entre as entidades. Usamos o contexto de dados do Entity Framework para realizar consultas. Quando uma das operações CRUD é invocada, a estrutura de entidades irá gerar o SQL necessário para realizar a operação.
É galera, mas como eu faço quando as tabelas não tem uma chave primária? Ou quando é utilizado sinônimos no banco? Ou databases diferentes? Tem como tbm?
Marcio Martins deu uma resposta interessante em outro fórum!
>
Cara, este é o grande problema do Entity.
O pessoal que começa aprendendo pelo Entity Framework não entende que ele é APENAS UM FRAMEWORK, e acaba se esquecendo de aprender o básico.
Seguinte: a maioria das empresas utiliza um modelo de 4 camadas, sendo elas:
- User Interface (UI - no seu caso, o MVC);
- Regras de Negócio (BLL - Business Logic Layer);
- Acesso a Dados (DAL - Data Access Layer);A Model Layer está presente em todas as camadas e serve para o transporte dos dados.
Quem preenche os objetos da ML é a DAL (Data Access Layer), que acessa o banco de dados e faz todas as operações de CRUD. E só. Não há regra de negócio nenhuma nesta camada.
As regras de negócio (todas) ficam na BLL (Business Logic Layer). Ela referencia a DAL para obter e salvar os objetos ML (modelos), depois de realizar as devidas regras de negócio.
A sua UI (MVC) vai chamar as classes BLL através dos seus Controllers. Veja bem: apenas CHAMAR. Não deve haver regra de negócio na sua Controller. A UI também pode pegar os dados da View e preencher um objeto ML (modelo) para enviar a uma BLL para processamento dos dados entrados pelo usuário na View.
Veja que não é legal você usar os objetos ML para preencher uma View, visto que o modelo que será útil para a view é mais especializado. Por isso eu crio ViewModels, que são modelos de dados que só servem para popular uma view. Eu preencho a ViewModel com os dados de um objeto ML e, com isso, posso mandar apenas os dados que minha View precisa para renderizar.
O caminho inverso também deve ser respeitado, pegando os dados da View (entrada do usuário) em uma ViewModel, e transformando esses dados em um (ou mais) objetos ML para envio para os respectivos objetos BLL para o processamento das regras de negócio.
Espero ter ajudado!
O básico, todo bom profissional sabe. Isso é essencial.
De modo que bons profissionais que utilizam ORM sabem exatamente o que estão fazendo.
O Entity Data Model Framework nada mais é que um ORM.
Sugiro que você crie uma Web App CRUD Simples no próprio MS SQL Server.
Veja na prática o que EF faz, você conferir por conta própria é melhor do que ler qualquer opinião de terceiros.
E como já disse, não sei qual banco de dados você pretende utilizar. Mas com certeza há EF Providers para praticamente todos os bancos de dados, muitos deles são projetos open-source, outros, são EF Providers comerciais.
Qual banco de dados você está utilizando?
Com certeza deve existir algum EF Provider comercial para o seu banco.
Se não for pra utilizar o EF, acho melhor utilizar o ASP.NET Web Form e dividir seus projeto em camadas, fica bem legal dessa forma também.
Sim, é possível utilizar o ASP.NET MVC sem EF, mas como você já mesmo disse, não há materiais na net mostrando isso porque não faz muito sentido. Na questão da produtividade, é totalmente improdutivo!