Pergunta

Estive lendo através de um par de perguntas aqui e vários artigos sobre MVC e pode ver como ele pode até mesmo ser aplicado para aplicações de uso intensivo de eventos GUI como um aplicativo de pintura.

Alguém pode citar uma situação onde MVC pode ser uma coisa ruim e seu uso imprudente?

EDIT: Eu estou falando especificamente sobre aplicações GUI aqui

Foi útil?

Solução

Eu tentei MVC em meu driver de kernel rede. O patch foi rejeitada.

Outras dicas

Eu acho que você está olhando para ele espécie de trás. O ponto não é para ver onde você pode aplicar um padrão como MVC, o ponto é para aprender os padrões e reconhecer quando o problema que você está tentando resolver naturalmente pode ser resolvido através da aplicação do padrão. Então, se o seu espaço de problema pode ser naturalmente dividida em modelo, vista e controlador, então é um bom candidato para MVC. Se você não pode ver facilmente quais partes do seu projeto queda em três categorias, pode não ser o padrão adequado.

MVC faz sentido para aplicações web. Em aplicações web, você processar alguns dados (on SA: escrever perguntas, adicionando comentários, alterar informações do usuário), você tem estado (usuário conectado), você não tem muitas páginas diferentes, mas um monte de conteúdo diferente para se encaixar essas páginas. Uma página Pergunta vs. um milhão de perguntas.

Para fazer CMS, por exemplo, MVC é inútil. Você não tem nenhum modelos, há controladores, apenas a páginas de texto com decorações e menus. O problema não está processando dados -. O problema agora está servindo de que o conteúdo do texto corretamente

Tho, CMS admin iria construir em cima do MVC muito bem, é apenas parte do usuário que não.

Para serviços web, é melhor utilização descanso que, creio eu, é um paradigma diferente.

WebDAV aplicação não iria beneficiar muito de MVC, também.

A ressalva sobre Ruby para a programação Web é que Rails é mais adequado para a construção Aplicativos da web. Tenho visto muitos projetos de tentar criar um servidor WebDAV ou um sistema de gerenciamento de conteúdo CMS com Rails e falhar miseravelmente. Enquanto você pode fazer um CMS em Rails, há muito mais eficientes tecnologias para a tarefa, tais como Drupal e Django. Na verdade, eu diria que se você está olhando para um esforço de desenvolvimento Java Portal, você deve avaliar Drupal e Django para a tarefa em seu lugar.

Qualquer coisa que você quer deixar cair em componentes 3rd party irá torná-lo difícil de trabalho no padrão MVC. Um bom exemplo disto é um CMS.

Cada componente você começa terão seus "próprios" objetos de controlador e você não será capaz de compartilhar "controle" do modelo -> ui passando.

Eu não necessariamente sabe que MVC é sempre realmente um mau idéia para um aplicativo GUI. Mas existem alternativas que são indiscutivelmente melhor (e também, sem dúvida, pior, dependendo cuja opinião você está perguntando). O mais comum é MVP. Veja aqui para uma explicação: Tudo que você queria saber sobre MVC e MVP Mas Tinha medo de Perguntar .

Embora eu suponho que poderia ser uma má idéia usar MVC se você estiver usando um quadro ou de outra forma interagir com o software que não foi projetado com MVC em mente.

Em outras palavras, é muito como comparar as linguagens de programação. Há geralmente não é muitas tarefas que se pode dizer que um é melhor que o outro para. Ele geralmente se resume a preferência programador, disponibilidade de bibliotecas e experiência da equipe.

MVC não deve ser utilizado em aplicações onde o desempenho é crítico. Eu não sei se isso ainda applys com o aumento do poder de computação, mas um exemplo é um aplicativo de call center. Se você pode salvar .5 segundos por entrada de chamadas e informações atualizar essas economias somam ao longo do tempo. Para obter o último bit de desempenho do seu aplicativo, você deve usar um aplicativo de desktop em vez de um aplicativo web e tê-lo falar diretamente com o banco de dados.

Quando é que é uma coisa ruim? Onde sempre há um outro código-estrutura que melhor se encaixam no seu projeto.

Há inúmeros projetos em que MVC não iria "ajuste", mas eu não vejo como uma lista deles seria de qualquer benefício ..

fits Se MVC, usá-lo, se não, use outra coisa ..

MVC e ORM são uma piada .... eles só são apropriadas quando seu aplicativo não é um aplicativo de banco de dados, ou quando você quiser manter o agnóstico banco de dados de aplicativo. Se você estiver usando um RDBMS que suporta procedimentos armazenados, então esse é o único caminho a percorrer. procs armazenados são a abordagem preferida para desenvolvedores de aplicativos experientes. MVC e ORM só são promovidos por empresas que tentam vender produtos ou serviços relacionados a essas tecnologias (por exemplo, Microsoft tentando vender VS). Pare de desperdiçar seu tempo aprendendo Java e C #, se concentrar no que realmente importa, Javascript e SQL.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top