DÊVIDA CONCEITUAL SOBRE ASP.NET MVC
Oi pessoal, tudo bem?
Estou estudando ASP.NET MVC e queria tirar uma dúvida sobre conceitos dele, na verdade, mas de MVC. A camada de regra de negócio fica na Model ou na Controller?
Grata!
Estou estudando ASP.NET MVC e queria tirar uma dúvida sobre conceitos dele, na verdade, mas de MVC. A camada de regra de negócio fica na Model ou na Controller?
Grata!
Oi Kelly!
Também quero aprender mais de MVC e atrelá-lo dentro de 3 camadas.
Pelo que eu entendi isso é perfeitamente possÃvel.
===========================================
é errado deixar regra de negócio nos controllers?
http://pt.stackoverflow.com/questions/32772/%C3%89-errado-deixar-regra-de-neg%C3%B3cio-nos-controllers
Sim, é errado. Validação de dados é uma caracterÃstica do tipo de dado, portanto, de responsabilidade do Model.
===========================================
[][ô]s,
Tunusat.
Também quero aprender mais de MVC e atrelá-lo dentro de 3 camadas.
Pelo que eu entendi isso é perfeitamente possÃvel.
===========================================
é errado deixar regra de negócio nos controllers?
http://pt.stackoverflow.com/questions/32772/%C3%89-errado-deixar-regra-de-neg%C3%B3cio-nos-controllers
Sim, é errado. Validação de dados é uma caracterÃstica do tipo de dado, portanto, de responsabilidade do Model.
===========================================
[][ô]s,
Tunusat.
O Controller serve apenas para direcionar o fluxo da sua aplicação.
A View para visualizar os dados
E o Model para gerenciar sua lógica de negócio
A View para visualizar os dados
E o Model para gerenciar sua lógica de negócio
KELLY,
Veja também:
=================================================
Padrões de Projeto : O modelo MVC - Model View Controller
http://www.macoratti.net/vbn_mvc.htm
=================================================
[][ô]s,
Tunusat.
Veja também:
=================================================
Padrões de Projeto : O modelo MVC - Model View Controller
http://www.macoratti.net/vbn_mvc.htm
=================================================
[][ô]s,
Tunusat.
Olha só... na minha experiência como programador eu observei que a arquitetura MVC sempre sofre algumas modificações conceituais durante um projeto. Eu trabalhei em algumas empresas e cada uma delas usavam conceitos ligeiramente diferentes uma das outras e do tido como tradicional.
Tradicionalmente nos temos:
Model ---> é onde fica toda sua regra de negócio e persistência de dados;
View ---> A interface com o usuário;
Controller ---> Seria uma espécie de fronteira entre o Model e a View. Ele faz o meio de campo mapeando os eventos.
Você vai ver vários livros sobre Design Patterns que vão encher de informação. Muitas delas úteis... Mas você precisa entender o conceito pra poder aplicar da forma que achar melhor. Simplesmente criar um padrão para seu projeto porque viu alguém fazendo não adianta. Tem que pesar a sua necessidade e também suas opções.
Lembra que te falei que haviam variações de uma empresa para a outra?
Todas se basearam em MVC. Mas cada uma tinha seu próprio Framework, assim como eu criei o meu também. Eu adotei a ideia de um framework objeto-relacional.
Isso já elimina todos os meus problemas de persistência do Model.
Basicamente eu tenho em meus projetos:
Model ---> Onde eu descrevo meu objeto, assim como defino os atributos relacionais com o banco de dados; (Só isso já me dá a principal vantagem do conceito MVC. Eu consigo fazer minha persistência de dados independente de qual interface usar).
View ---> Meus formulários, userControls, etc;
E por fim, meu Controller. Esse é de longe o item que causa maiores dúvidas em relação a maioria das pessoas. Simplesmente, porque a ideia principal do MVC é fazer com que sua regra de negócio independa da sua View. Então seria dividir o Model da View. Sendo a View um conceito bem visual e fácil de entender, fica fácil então. Então onde entra o Controller?
Já vi empresas que usavam em seus padrões o Controller como um objeto que dispara eventos. Simplesmente ele era chamado para chamar o Model. Conceitualmente isso está correto. Mas a partir do momento que você possui um framework de persistência, por que simplesmente não persistir dentro da própria view?
Com o meu framework, eu consigo simplesmente deixar o meu Controller como o alimentador da View. Então se eu tenho que exibir algo num ListView, por exemplo, eu chamo o método do Controller que me retorna os valores, ou até mesmo um Model, ou uma coleção deles... e mando bala.
De qualquer forma, o principal que você precisa entender no MVC é saber separar seu código de forma que ele fique reaproveitável. Se parar pra pensar, não é tão diferente do conceito de Orientação a Objetos.
Não gosto muito de regras em programação, acredito que todos os conceitos são apenas bases para você criar o que é melhor para o seu tipo de desenvolvimento. Mas tente seguir isso que se dará bem:
Regra 1 - Nunca deixe seu Model saber da existência do seu Controller, muito menos da View;
Regra 2 - Nunca deixe a sua regra de negócio fora do Model;
Regra 3 - Tente dividir ao máximo seu código, de forma que todas as partes funcionem de forma independente. Você irá perceber que as 3 camadas podem ser subdivididas.
Regra 4 - A View nunca terá conhecimento do seu banco de dados.
Tem outras, mas isso você vai pegando com a prática.
Não sou um especialista, mas é o que aprendi nesses meus anos de desenvolvimento. Espero ter ajudado!
Tradicionalmente nos temos:
Model ---> é onde fica toda sua regra de negócio e persistência de dados;
View ---> A interface com o usuário;
Controller ---> Seria uma espécie de fronteira entre o Model e a View. Ele faz o meio de campo mapeando os eventos.
Você vai ver vários livros sobre Design Patterns que vão encher de informação. Muitas delas úteis... Mas você precisa entender o conceito pra poder aplicar da forma que achar melhor. Simplesmente criar um padrão para seu projeto porque viu alguém fazendo não adianta. Tem que pesar a sua necessidade e também suas opções.
Lembra que te falei que haviam variações de uma empresa para a outra?
Todas se basearam em MVC. Mas cada uma tinha seu próprio Framework, assim como eu criei o meu também. Eu adotei a ideia de um framework objeto-relacional.
Isso já elimina todos os meus problemas de persistência do Model.
Basicamente eu tenho em meus projetos:
Model ---> Onde eu descrevo meu objeto, assim como defino os atributos relacionais com o banco de dados; (Só isso já me dá a principal vantagem do conceito MVC. Eu consigo fazer minha persistência de dados independente de qual interface usar).
View ---> Meus formulários, userControls, etc;
E por fim, meu Controller. Esse é de longe o item que causa maiores dúvidas em relação a maioria das pessoas. Simplesmente, porque a ideia principal do MVC é fazer com que sua regra de negócio independa da sua View. Então seria dividir o Model da View. Sendo a View um conceito bem visual e fácil de entender, fica fácil então. Então onde entra o Controller?
Já vi empresas que usavam em seus padrões o Controller como um objeto que dispara eventos. Simplesmente ele era chamado para chamar o Model. Conceitualmente isso está correto. Mas a partir do momento que você possui um framework de persistência, por que simplesmente não persistir dentro da própria view?
Com o meu framework, eu consigo simplesmente deixar o meu Controller como o alimentador da View. Então se eu tenho que exibir algo num ListView, por exemplo, eu chamo o método do Controller que me retorna os valores, ou até mesmo um Model, ou uma coleção deles... e mando bala.
De qualquer forma, o principal que você precisa entender no MVC é saber separar seu código de forma que ele fique reaproveitável. Se parar pra pensar, não é tão diferente do conceito de Orientação a Objetos.
Não gosto muito de regras em programação, acredito que todos os conceitos são apenas bases para você criar o que é melhor para o seu tipo de desenvolvimento. Mas tente seguir isso que se dará bem:
Regra 1 - Nunca deixe seu Model saber da existência do seu Controller, muito menos da View;
Regra 2 - Nunca deixe a sua regra de negócio fora do Model;
Regra 3 - Tente dividir ao máximo seu código, de forma que todas as partes funcionem de forma independente. Você irá perceber que as 3 camadas podem ser subdivididas.
Regra 4 - A View nunca terá conhecimento do seu banco de dados.
Tem outras, mas isso você vai pegando com a prática.
Não sou um especialista, mas é o que aprendi nesses meus anos de desenvolvimento. Espero ter ajudado!
Citação::
Oi Kelly!
Também quero aprender mais de MVC e atrelá-lo dentro de 3 camadas.
Pelo que eu entendi isso é perfeitamente possÃvel.
===========================================
é errado deixar regra de negócio nos controllers?
http://pt.stackoverflow.com/questions/32772/%C3%89-errado-deixar-regra-de-neg%C3%B3cio-nos-controllers
Sim, é errado. Validação de dados é uma caracterÃstica do tipo de dado, portanto, de responsabilidade do Model.
===========================================
[][ô]s,
Tunusat.
Oi Tunusat, sim, além do ASP.NET MVC ter as suas três camadas por padrão você também pode criar outras três camadas para organizar ainda mais o projeto. No youtube tem alguns vÃdeos de ASP.NET MVC na Prática, mas acabei ficando com essa dúvida que postei aqui porque uns dizem que a Model só contem classes com regras de presistência de dados e outros já dizem o contrário. E já vi também falaram que é na Controller que são definidas as regras de negócio onde vai definir e gerenciar se os dados devem irm para a camada de persistência ou não da aplicação.
Citação::
O Controller serve apenas para direcionar o fluxo da sua aplicação.
A View para visualizar os dados
E o Model para gerenciar sua lógica de negócio
Boa tarde Jaba, eu estou com essa grande dúvida entre as camadas View e Controller, mas pelas aulas que o DS2T deu aqui neste tópico deu para entender o funcionamento das regras.
Obrigada amigos!
Tópico encerrado , respostas não são mais permitidas