Eu preciso explicar o MVC para não programadores. Ou seja, para gerentes de outros departamentos, no contexto do relatório de progresso. Uma das coisas que faço é refatorar nossa base de código para a separação do MVC.

O que é a separação MVC que eles podem perguntar? Por que é necessário que eles perguntem?

Depois de ler uma resposta bastante técnica como esta: O que é MVC, realmente? , Não estou totalmente satisfeito, pois falarei com não programadores. Eles podem acenar com a cabeça, mas provavelmente não entenderão o que é e por que é necessário.

Na realidade, não entendo completamente o que é MVC, a não ser "separação de preocupações, deveres, funções, classes, blocos, tarefas, coisas, a fim de melhorar a flexibilidade de fazer alterações no software". Separar banco de dados de visão e visão da lógica de negócios usando técnicas como ferramentas e técnicas de DI e OO é algo que considero separação do MVC.

Então, da próxima vez que você estiver explicando o MVC a um não programador com experiência em vendas e contabilidade, por exemplo, o que você diria a eles?

Você não explica o MVC.

O que você faz é explicar que essa é uma reestruturação da base de código.

Uma reestruturação que simplifica a base de código e, portanto, permite que os desenvolvedores façam alterações mais rápidas e melhores em relatórios de bugs e solicitações de recursos, com menos bugs.

Eles não precisam conhecer os detalhes técnicos, apenas por que isso foi feito, o que foi alcançado com isso e como os negócios se beneficiam.

Em outras palavras - fale sua língua para eles.

Embora eu apóie a essência da resposta de Oded , que você explique projetos técnicos para os gerentes de negócios em "seu idioma", tenho uma dúvida sobre "eles não precisam saber detalhes técnicos, apenas por que isso foi feito".

Se você estiver em uma reunião de revisão de projeto ou investimento com chefes de departamento e declarar "é isso que estamos fazendo", eles podem perguntar "Umm ... por quê? Isso parece ser um grande investimento de tempo e energia. Você poderia nos dar um pouco mais de compreensão do que está fazendo e por quê? " Essa parece uma pergunta eminentemente razoável. Você não quer ser pego na posição de "Bem ... é complicado". ou "Não, eu realmente não posso explicar isso". ou "Não se preocupem com isso". Quanto mais sênior a equipe para a qual você está revisando o projeto, menor a probabilidade de deixarem "apenas coisas que não posso explicar bem". Melhor se você puder ir pelo menos um nível mais fundo para fazer com que os outros se sintam à vontade de que 1) você sabe o que está fazendo '

Então, tenha um esboço do MVC no seu bolso, pronto para usar. Algo como:

"É um pouco técnico, mas ... O MVC divide o código em Modelos (responsável pelos dados principais e pela lógica de negócios), Visualizações (que exibe os dados) e Controladores (que lidam com as interações e atualizações do usuário). É uma arquitetura comprovada - - possivelmente o "padrão de design" mais bem-sucedido da engenharia de software. Sei que pode parecer "apenas um encanamento", mas para lidar com todos os pedidos recebidos, precisamos de uma base mais sólida. Isso nos colocará no caminho certo para construir novas recursos e resolva erros mais rapidamente. "

Mesmo que eles não entendam completamente o MVC no final, e mesmo que você tenha que simplificar demais para torná-lo compreensível ("quebre alguns ovos para fazer uma omelete"), aposto que você achará muito mais confortável tenha uma explicação pronta para dizer "não posso explicar" ou "você não está qualificado para entendê-la" para os gerentes seniores.

para melhorar a flexibilidade de fazer alterações no software

Os gerentes estão interessados ​​no resultado final. Quanto menos técnicos, menor a probabilidade de eles se preocuparem com a maneira como você chega lá. MVC é muito comum, popular e comprovado.

Quando solicitações de mudança são feitas no futuro, você pode informar à gerência que elas podem ser feitas mais fácil e rapidamente. Todo mundo gosta de ouvir isso.

É uma estratégia comum, portanto, contratar novos desenvolvedores não deve representar um problema. De fato, você pode atrair melhores desenvolvedores que são fortes defensores.

Tudo isso será muito difícil se houver muitas questões urgentes nesse projeto em particular. Eles podem não estar dispostos a dar um passo atrás, para que você possa dar dois passos adiante. A solução pode ser esperar ou implementar em pedaços menores.

• Modelo - Fios / eletricidade
• Vista - Luminária
• Controlador - interruptor de luz

Relativamente fácil de trocar os componentes (luminária, interruptor de luz / dimmer). Talvez não tanto a fiação, mas ainda pode ser feita sem afetar outros componentes. Todos devem ser capazes de visualizar isso na sua cabeça, mesmo tipos de marketing / vendas. (Separação clara, etc.)

Agora diga ao seu chefe / colegas de trabalho que, em nosso aplicativo / sistema, o interruptor está incorporado dentro da luminária e a luminária é enrolada em fio de cobre. Agora imagine tentar atualizar a luminária, o interruptor ou o fio. Muito caro, impacto em outros componentes muito alto e talvez perigoso, sem quebrar outra coisa.

O MVC está aplicando um padrão à base de código que transforma a bagunça confusa (mas funcionando) em algo em que as mudanças podem acontecer de maneira mais rápida e fácil com menos erros.

Uma maneira fácil de entender o MVC: o modelo são os dados , a visualização é a janela na tela e o controlador é a cola entre os dois .

A melhor rubrica de todos os tempos: "Precisamos de modelos SMART, controladores THIN e vistas DUMB"

Como em outros padrões de design de software, o MVC expressa o " núcleo da solução " para um problema, permitindo que ele seja adaptado para cada sistema. É melhor visto como um conceito em vez de uma implementação específica. Existem muitas implementações do conceito.

Todas as variantes do MVC usam a mesma divisão de componentes, mas geralmente diferem na maneira como esses componentes interagem.

Para aqueles que não sabem, o MVC foi originalmente descrito em termos de um padrão de design para uso com Smalltalk por Trygve Reenskaug em 1979 . Seu artigo foi publicado sob o título "Programação de aplicativos no Smalltalk-80: Como usar o Model-View-Controller" e abriu as bases para a maioria das futuras implementações de MVC.

Eu concordo parcialmente com Oded - aprendendo a convencer seus colegas e gerentes não técnicos de que o que você está fazendo é importante e útil, sem explicar os detalhes, é uma habilidade necessária que você deve desenvolver.

No entanto, acredito que ter a capacidade de explicar conceitos complexos em termos simples realmente ajuda com isso - um problema que os gerentes não técnicos costumam ter é que, como eles têm dificuldade em entender exatamente o que as pessoas de tecnologia estão fazendo, elas tendem a desconfie deles. É apenas a natureza humana: é mais fácil acreditar que algo que você não entende é inútil ou errado do que confiar nela. Portanto, se você pode facilitar a compreensão de conceitos à vontade, pode usar isso sempre que precisar e, com o tempo, seus gerentes não técnicos aprenderão que eles podem entender se quiserem - você não está tentando convencê-lo neles - você está poupando-lhes os detalhes para sua própria sanidade. Eles confiarão mais em você.

Além disso, vamos responder à pergunta:

Acho útil usar analogias que os empresários entendem. Para MVC, eu descrevo isso como um negócio.

• Os modelos são responsáveis ​​pela lógica e pelos dados dos negócios - são as coisas que definem o que o programa faz e os detalhes de como ele faz. Se o programa fosse um negócio, os modelos seriam os armazéns, fábricas, trabalhadores e equipamentos de capital. Eles também seriam os gerentes de nível inferior que garantem que as regras sejam seguidas e as políticas sejam aplicadas.
• As visualizações são a camada de apresentação - elas mostram aos usuários o que está acontecendo no sistema e fornecem um meio de interagir com o programa. Se o nosso programa fosse uma empresa, as visualizações seriam como o salão do showroom, o estande de vendas da convenção comercial ou os representantes de vendas. Eles exibem opções, fornecem informações e comentários fáceis de usar e levam solicitações de volta à empresa.
• Os controladores são a camada de coordenação - eles garantem que as informações cheguem dos modelos às visualizações e vice-versa, e que tudo funcione em conjunto para realizar seu trabalho. Se o programa fosse uma empresa, os controladores seriam a gerência de nível médio e alto. Eles não se envolvem muito nos detalhes, mas garantem que as pessoas certas tenham as ferramentas certas para fazer seu trabalho e aprovam ou negam decisões de alto nível. Eles fornecem a direção geral para que as coisas possam funcionar juntas.

O benefício de explicá-lo com essa analogia é que um bom gerente enxerga a sabedoria em separar as preocupações dessa maneira e pode decidir que elas devem ser mais controladoras e não se envolver demais nos detalhes no futuro!

Esperamos que isso responda o "o quê" - o "porquê" também é fácil com essa analogia:

Imagine uma empresa ideal, onde cada departamento é responsável por um conjunto de tarefas e sabe que sempre terá os recursos de que precisa sem ter que se preocupar com o que os outros estão fazendo. Um representante de vendas encontra um cliente, recebe seu pedido, passa-o de volta para a gerência que aprova e depois vai para o armazém / produção / engenharia para atendimento. O feedback é direto - ninguém mais precisa se envolver, a menos que haja um problema. Esse é um bom design do MVC - cada parte tem um trabalho e não precisa se preocupar com outras partes. Dessa forma, é fácil mudar se for necessário. Em um design não MVC, as responsabilidades não são claras. O representante de vendas pode tentar modificar o produto quando o cliente pede algo diferente. Ou eles podem oferecer preços diferentes, dependendo de como se sentiram naquele dia. O CEO pode estar no chão da fábrica mexendo com a linha de produção, quando deve estar preocupado com a forma de implantar uma cadeia de suprimentos mais confiável. Os trabalhadores do armazém podem estar no chão de vendas conversando com os clientes quando eles devem estar cumprindo os pedidos que já foram recebidos.

Em outras palavras, o bom design do MVC permite que cada parte se concentre em uma coisa, para que possa fazer o que é certo - como uma empresa bem organizada.

** Isenção de responsabilidade - se sua empresa estiver mal organizada, ela poderá se ofender com isso. Nesse caso, você precisará de outra analogia. Você também pode precisar de um emprego diferente.

Os benefícios do MVC estão principalmente na separação de preocupações:

Permite que as pessoas se concentrem no que fazem melhor.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

Reduz os custos porque os sistemas entrelaçados exigem que a equipe seja especialista em todas essas áreas ou é mais provável que você tenha problemas quando uma mudança em uma área afeta as outras.

Forneça exemplos reais de arquiteturas MVC: telefones celulares, telefones de mesa, Skype, etc. Alterar a exibição (tipo de teclado de discagem, alto-falantes, microfones) não afeta o modelo (o sinal de áudio), o controlador é o circuito no o telefone que traduz as ondas sonoras em sinais de áudio.

Eu diria a eles que o MVC separa minhas preocupações.

Minha primeira preocupação é a lógica do código - o que faço nos bastidores para fazer o site executar as ações que ele deseja.

Minha segunda preocupação é a lógica de negócios - o que eles (o usuário) desejam que o aplicativo faça.

Minha terceira preocupação é a aparência do site - a página que eles visitam para fazer o que querem.

(Eu não lhes diria a próxima parte). Então, em ordem, minhas explicações foram para o Model, Controller e View.

Explique as vantagens

Eu explicaria o MVC em termos de benefícios comerciais. Seus gerentes serão capazes de entender isso e embarcarão se as vantagens forem convincentes.

O MVC permite decompor seu aplicativo em unidades sensíveis, cada uma das quais existe independentemente das outras. Você obtém código limpo, sustentável, testável e potencialmente reutilização de código entre sistemas.

O Modelo

Cada modelo encapsula um único tipo de informação comercial, por exemplo, um registro de cliente ou um produto, juntamente com toda a lógica comercial relacionada.

Separar isso permite que você teste facilmente sua lógica de negócios isoladamente de outras partes do seu aplicativo.

Você também pode estender facilmente o aplicativo adicionando modelos adicionais, é muito modular e limpo.

Cada modelo em teoria pode existir independentemente dos outros. Você pode aplicar isso usando objetos de serviço para lidar com relacionamentos entre modelos. Você pode trocar de modelo sem afetar o restante do sistema.

A vista

Separar sua visualização permite que você atualize facilmente seu front end sem interromper o backend subjacente.

Você pode fornecer seu código de front-end para outro desenvolvedor sem necessariamente fornecer acesso a todo o sistema.

Você também pode criar front-ends alternativos que funcionam com o sistema existente. Você pode mostrar seus dados como um aplicativo móvel, uma API, um PDF ou uma planilha do Excel. Você pode fazer isso sem invadir o resto do sistema. Você tem menos chances de quebrar as coisas acidentalmente. Você pode criar facilmente pontos de integração para os sistemas existentes se conectarem.

O controlador

O controlador liga os modelos à vista. Mantém tudo separado. Você pode conectar uma visualização diferente com muita facilidade. Se você alterar o código do modelo, a visualização nem precisará saber.

Outras vantagens

É um padrão comum. Outros desenvolvedores poderão entender seu código e trabalhar nele. Se você retornar ao seu código anos depois, provavelmente será capaz de entendê-lo e fazer alterações. É menos provável que seu código se torne outra dor de cabeça herdada para um desenvolvedor futuro.

Como tudo tem um lugar, é muito mais fácil produzir código limpo. O risco de spaghettification é reduzido drasticamente (embora não seja eliminado). Seu código se torna sustentável.

Como tudo é modular, você pode testar partes dele isoladamente. Seu código é testável e tem menor probabilidade de abrigar bugs ou falhas de segurança. As atualizações futuras serão muito mais fáceis, pois você poderá testar facilmente todo o sistema.