ASP.NET MVC Sem Entity

[Fabricio F. Vieira 3]

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!

[Alan Walking 5]

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!

[xanburzum 169]

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.

[Fabricio F. Vieira 3]

É 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:

1. User Interface (UI - no seu caso, o MVC);
2. Regras de Negócio (BLL - Business Logic Layer);
3. Acesso a Dados (DAL - Data Access Layer);
4. Modelos (ML - Model 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!

[Alan Walking 5]

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.