Onde está o M no MVC?

Estou tentando refatorar meu aplicativo no MVC, mas estou preso na parte M.

Em um aplicativo suportado por banco de dados, o modelo é implementado no código do aplicativo, certo?

Mas então, o que há no banco de dados - esse também não é o modelo?

(Não estou usando o banco de dados como um simples armazenamento de objetos - os dados no banco de dados são um ativo da empresa).

Sim, o modelo no código e o banco de dados são o "Modelo".

O modelo tem a ver com o que a sua aplicação "IS" e o controlador é o que "faz". Qualquer código que lida com persistência direta no banco de dados é considerado o Modelo.

Nota: MVC é um padrão , portanto, não pense demais. É fácil convencer todo mundo a fazer MVC da maneira certa, mas no final do dia, é apenas uma mentalidade! Isso significa manter sua lógica de negócios fora do banco de dados e da interface do usuário - é isso. Antes do MVC, as pessoas colocavam a lógica de negócios em todas as suas páginas da Web quando deveria estar no servidor, ou eles tinham vários scripts disparando no banco de dados, fazendo a lógica de negócios junto com o código de persistência. O MVC foi criado para levar as pessoas a pensarem de uma maneira que ajude a tornar seu código reutilizável, portanto, não se prenda aos detalhes demais.

Trygve Reenskaug escreveu os documentos iniciais que descrevem o padrão MVC em 1978. O Modelo em sua descrição era o modelo de objeto que representa objetos, fenômenos e conceitos do mundo real. No seu cenário de um aplicativo suportado por banco de dados, o modelo é uma projeção de seus dados. Simplificando, o modelo são as classes e seus relacionamentos com os quais seu aplicativo se preocupa.

Na prática, geralmente existem dois modelos usados ​​no MVC, o Modelo de Domínio (o que está mapeando para seu banco de dados) e o Modelo de Aplicativo (também chamado de Modelo de Visualização na terminologia de hoje). O Modelo de Aplicativo é uma projeção do Modelo de Domínio que também contém dados específicos da exibição para renderizar a exibição. Essa abordagem é chamada MMVC . O controlador interage diretamente com o modelo de domínio e apresenta um modelo de aplicativo para a visualização. No padrão MVVM, o Modelo de Aplicação e o Controlador são combinados.

1. Você não precisa de um banco de dados para MVC. Se o seu modelo falar com o banco de dados, ótimo. Também pode persistir em um arquivo simples ou não persistir.

2. O modelo é onde os dados são armazenados na memória do seu aplicativo. Você também desejará usar o modelo para fazer cálculos e validações em seus dados. Por exemplo, você tem um modelo FinancePayment, com propriedades como taxa de juros, prazo e princípio. Você pode adicionar um método getMonthlyPayment () ao seu modelo para calcular o pagamento mensal. Você não gostaria de fazer isso no controlador ou na exibição.

3. A visão deve ser razoavelmente boba, ou não possui lógica alguma, ou usa apenas uma ligação de dados simples (consulte Visão passiva e padrões de controlador de supervisão no site de Martin Fowler ). A visualização gera eventos quando o usuário faz coisas, como clicar em um botão.

4. O controlador é responsável por manipular eventos (execute algum código quando o usuário clicar no botão salvar), e por definir as propriedades do modelo e dizer ao modelo para carregar e salvar a si mesmo (se estiver usando persistência). O controlador não deve estar fazendo cálculos nos dados do modelo. No entanto, no controlador, você pode fazer alguns cálculos em nome da visualização, como "if model.profit () <0 then widget.colour = 'red'"

5. Você deve poder mudar para uma versão de linha de comando do seu aplicativo sem alterar os modelos e sem perder a funcionalidade dos modelos.

uma. Provavelmente, você poderá mudar para uma versão móvel do seu aplicativo (em vez de uma versão para desktop) alternando apenas as visualizações (e não os controladores ou modelos). Você deve poder testar seus modelos e controladores sem uma estrutura de teste da GUI.

Model é o código que possui conexão com V e C no front-end e no armazenamento persistente (pode ser qualquer coisa, de arquivos a bancos de dados SQL / NoSQL) no back-end. Não é apenas o código que carrega de db e armazena em db (que é um dos mal-entendidos do modelo), é o código que realmente faz todo o trabalho do "domínio" - seleciona, filtra, altera, calcula e decide sobre o dados. Inclui toda a lógica não-UI do aplicativo.

Tomando uma visão muito simplista e idealista.

O Modelo geralmente é visto como um modelo do domínio (aproximadamente, o negócio), não como um modelo dos dados. Eles podem parecer semelhantes, mas não estão completamente ligados um ao outro.

A Visualização deve ser um modelo do front end do aplicativo e o Controlador deve ser um modelo do fluxo de uma visualização para outra.

A lógica de negócios deve ser totalmente encapsulada no modelo, seja no banco de dados ou no código. Embora algumas lógicas de negócios possam ser repetidas no View ou Controller, por vários motivos, deve ser possível (e seguro) remover completamente esses dois componentes e colocar um front-end diferente em seu lugar.

No meu entender, MVC é apenas a descrição do padrão arquitetural do seu aplicativo cliente. A imagem aqui na Wikipedia apenas mostra isso:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Obviamente, quando você implementa partes de seu aplicativo em "procedimentos armazenados", o código do banco de dados também pode fazer parte do modelo ou mesmo do controlador (dependendo do que o código faz). Mas se esse não for o caso, o banco de dados estará claramente "fora do MVC", exatamente como você afirmou.

But then, what is in the database -- is that not also the model?

Não não é. " O modelo gerencia o comportamento e os dados do domínio do aplicativo". Freqüentemente, o Modelo se conecta a um banco de dados sim, mas isso não é de forma alguma um requisito. O modelo é uma nova camada entre seu aplicativo e o banco de dados. O back-end pode ser um conjunto de objetos Mock, XML ou qualquer outra coisa que suporte a persistência de dados.

Ao desacoplar as camadas, você obtém uma flexibilidade muito maior para usar melhores práticas de teste de unidade, torna o código mais gerenciável (o EG SQL é substituído pelo Oracle), entre outros benefícios.

O mesmo acontece com o controlador. O MVC define o controlador como um intermediário entre as duas camadas. Não há "camada de negócios" definida no MVC. Em vez disso, você adiciona o seu próprio. O MVC não encapsula todas as camadas necessárias para criar a maioria dos aplicativos. É apenas uma orientação geral para a estrutura básica.

Essas separações são essenciais para permitir que a inversão de controle funcione.

O banco de dados é um detalhe de implementação do modelo. O modelo deve ser um modelo de domínio completo e combinar dados e processos. A separação deve ser entre preocupações de diferença e não entre um processo e os dados relacionados a esse processo.

Veja também: http://martinfowler.com/bliki/AnemicDomainModel.html

Na verdade, é muito simples, "Modelo" representa a abstração da interface de dados. É por isso que:

• Os bancos de dados são considerados parte do modelo , mas não o próprio modelo
• Os dados do modelo podem vir de bancos de dados, arquivos, serviços da web ou até mesmo serem zombados.
• Classes de modelo em MVC, HMVC ou estruturas similares devem armazenar consultas (consulte o princípio "modelo de gordura, controlador de interface" [ 1 ] [ 2 ] [ 3 ])

E, se eu estiver correto, é por isso que quando alguém se refere a modelos fora do contexto do MVC, é provável que alguém se refira à estrutura dos dados (ou seja, esquema ).

Eu acho que o M contém alguma lógica e armazena dados no DB. O controlador chama qual módulo seria executado e este módulo executará lógicas e armazenará dados no DB (pode haver uma camada persistente) e, em seguida, esse módulo retornará o valor para V.

O M (odel) no MVC deve capturar o modelo do negócio / domínio em um único local.

Idealmente, isso deve incluir regras de negócios do domínio e de sua estrutura.

O C (controlador) deveria, idealmente, preocupar-se apenas em mediar as informações do modelo de negócios na apresentação (por exemplo, na Visualização) e capturar a entrada do usuário de V (iew) para iniciar alterações no estado do modelo.

A camada do banco de dados lida apenas (ou melhor, deve lidar apenas) com a persistência do estado do modelo em determinado momento.

Como tal, não é algo que pertença à parte Model ou Controller do padrão MVC, mas é uma preocupação completamente separada que pode ser implementada implicitamente persistindo de forma transparente qualquer alteração no modelo (em função da fachada, fornecendo o interações com o seu modelo para o controlador) ou, como é feito com mais frequência, chamado explicitamente pelo controlador após terminar de fazer mutações no modelo.

O modelo em um mundo ideal deve conter apenas lógica de negócios, ele modela algum objeto real, como uma Casa. No entanto, em quase todas as circunstâncias, o modelo precisa manter seus dados em algum armazenamento.

As interações entre o modelo e os dados armazenados podem ocorrer em uma camada de dados separada ou diretamente no modelo, como é o caso ao usar um ORM (Object Relational Mapper). Em outras palavras, o modelo se conecta diretamente ao banco de dados ou passa seus dados para algum outro objeto de "acesso a dados" que se conecta ao banco de dados.

Um ORM (Mapeador de Relação de Objeto) mapeia os campos na tabela do banco de dados para os atributos do seu objeto de modelo, fornecendo getters e setters. Nesse caso, não há camada de dados separada e o modelo é diretamente responsável pela persistência de seus dados.

Aqui está um exemplo de Ruby usando ActiveRecordum ORM popular:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Priceé um campo na housestabela que é automaticamente detectado pelo ActiveRecordqual adiciona um getter e um setter ao objeto. Quando saveé chamado, o valor do atributo price é mantido no banco de dados.

Do meu ponto de vista, o profissional de ter uma camada de dados é que você obtém um ponto no qual pode manipular os dados antes que eles cheguem ao modelo, o modelo tem menos com o que se preocupar, tem menos responsabilidades. Por exemplo, pode ser necessário combinar dados de várias fontes de dados não compatíveis, isso é algo que um ORM não pode manipular facilmente.

O principal argumento é sua outra camada de abstração para gerenciar, se você não precisar, não se incomode, mantenha-o simples. Menos peças móveis, menos para dar errado.

Sim você está certo.

(Controlador de visualização de modelo)

Uma arquitetura para criar aplicativos que separam os dados (modelo) da interface com o usuário (visualização) e o processamento (controlador).

Na prática, as visualizações e os controladores do MVC são frequentemente combinados em um único objeto porque estão intimamente relacionados. De acordo com o MSDN

O controlador interpreta as entradas do mouse e teclado do usuário, informando o modelo e / ou the view to change as appropriate.

Verifique este diagrama:

Por exemplo, o código do controlador valida uma solicitação de dados e faz com que ela seja retornada em uma exibição. Os objetos do controlador de exibição estão vinculados a apenas um modelo; Contudo,a model can have many view-controller objects associated with it.