Abordagens “arquitetônicas” alternativas para o código do cliente JavaScript?

StackOverflow https://stackoverflow.com/questions/32540

Pergunta

Como seu código JavaScript está organizado?Segue padrões como MVC ou algo mais?

Estou trabalhando em um projeto paralelo há algum tempo e, quanto mais avanço, mais minha página se transforma em um aplicativo completo.No momento, estou mantendo jQuery, no entanto, a lógica da página está crescendo a um ponto em que alguma organização, ou ouso dizer, "arquitetura" é necessária.Minha primeira abordagem é "MVC-ish":

  • O 'modelo' é uma árvore JSON que é estendida com ajudantes
  • A visualização é o DOM mais as classes que a ajustam
  • O controlador é o objeto onde eu conecto a manipulação de eventos e inicio a visualização ou manipulação do modelo

Estou muito interessado, entretanto, em como outras pessoas criaram aplicativos JavaScript mais substanciais.Não estou interessado no GWT ou em outras abordagens orientadas a servidores...apenas na abordagem de "javaScript + <serviço web genérico-y aqui>"

Observação:anteriormente eu disse que javaScript "não é realmente OO, não é realmente funcional".Isso, eu acho, distraiu todo mundo.Vamos colocar desta forma, porque o javaScript é único em muitos aspectos, e venho de uma formação fortemente tipada, não quero forçar paradigmas que conheço, mas que foram desenvolvidos em linguagens muito diferentes.

Foi útil?

Solução

..mas Javascript tem muitas facetas que são OO.

Considere isto:

var Vehicle = jQuery.Class.create({ 
   init: function(name) { this.name = name; } 
});

var Car = Vehicle.extend({ 
   fillGas: function(){ 
      this.gas = 100; 
   } 
});

Usei essa técnica para criar classes javascript no nível da página que possuem seu próprio estado, o que ajuda a mantê-lo contido (e frequentemente identifico áreas que posso reutilizar e colocar em outras classes).

Isso também é especialmente útil quando você tem componentes/controles de servidor que possuem seu próprio script para executar, mas quando você pode ter várias instâncias na mesma página.Isso mantém o estado separado.

Outras dicas

JavaScriptMVC é uma ótima opção para organizar e desenvolver um aplicativo JS em grande escala.

O projeto de arquitetura muito bem pensado.Existem 4 coisas que você fará com JavaScript:

  1. Responder a um evento
  2. Solicitar dados/manipular serviços (Ajax)
  3. Adicione informações específicas do domínio à resposta ajax.
  4. Atualizar o DOM

JMVC os divide no padrão Model, View, Controller.

A primeira, e provavelmente a vantagem mais importante, é o Controlador.Os controladores usam delegação de eventos, portanto, em vez de anexar eventos, você simplesmente cria regras para sua página.Eles também usam o nome do Controlador para limitar o escopo de trabalho do controlador.Isso torna seu código determinístico, ou seja, se você vir um evento acontecer em um elemento '#todos', você sabe que deve haver um controlador de todos.

$.Controller.extend('TodosController',{
   'click' : function(el, ev){ ... },
   '.delete mouseover': function(el, ev){ ...}
   '.drag draginit' : function(el, ev, drag){ ...}
})

Em seguida vem o modelo.JMVC fornece uma classe poderosa e um modelo básico que permite organizar rapidamente a funcionalidade Ajax (nº 2) e agrupar os dados com funcionalidade específica de domínio (nº 3).Quando concluído, você pode usar modelos do seu controlador como:

Todo.findAll({depois:new Date()}, minhaCallbackFunction);

Finalmente, quando seus todos voltarem, você deverá exibi-los (#4).É aqui que você usa a visão do JMVC. 

'.show click' : function(el, ev){ 
   Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
   $('#todos').html( this.view(todos));
}

Em 'views/todos/list.ejs'

<% for(var i =0; i < this.length; i++){ %>
   <label><%= this[i].description %></label>
<%}%>

JMVC oferece muito mais que arquitetura.Ele ajuda você em todas as partes do ciclo de desenvolvimento com:

  • Geradores de código
  • Teste integrado de navegador, Selenium e Rhino
  • Documentação
  • Compressão de script
  • Relatório de erros

MochiKit é ótimo - e foi meu primeiro amor, por assim dizer, no que diz respeito às bibliotecas js.Mas descobri que, embora o MochiKit tenha uma sintaxe muito expressiva, ele não parecia tão confortável para mim quanto o Prototype/Scriptaculous ou o jQuery.

Acho que se você conhece ou gosta de python, o MochiKit é uma boa ferramenta para você.

Obrigado a todos gentilmente por suas respostas.Depois de algum tempo, gostaria de postar o que aprendi até agora.

Até agora, vejo uma diferença muito grande na abordagem usando algo como Externo, e outros como IU JQuery, Escriturário, Kit Mochi, etc.

Com Ext, o HTML é apenas um espaço reservado - a UI vai aqui.A partir de então, tudo é descrito em JavaScript.A interação do DOM é minimizada em outra camada de API (talvez mais forte).

Com os outros kits, começo fazendo um pouco de design HTML e, em seguida, estendendo o DOM diretamente com efeitos interessantes, ou apenas substituindo a entrada do formulário aqui, uma adição ali.

As principais diferenças começam a acontecer conforme preciso lidar com o tratamento de eventos, etc.Como os módulos precisam "conversar" entre si, preciso me afastar do DOM, abstraindo-o em pedaços.

Observo que muitas dessas bibliotecas também incluem algumas técnicas interessantes de modularização.Uma descrição muito clara é fornecida no site da Ext, que inclui uma maneira sofisticada de "proteger" seu código com módulos.

Um novo jogador que avaliei completamente é Sproutcore.Parece uma abordagem Ext, onde o DOM está oculto e você deseja lidar principalmente com a API do projeto.

Tristan, você descobrirá que quando tenta arquitetar o JavaScript como um aplicativo MVC, ele tende a falhar em uma área: o modelo.A área mais difícil de lidar é o modelo porque os dados não persistem em toda a aplicação e, por natureza, os modelos parecem mudar no lado do cliente de forma bastante consistente.Você poderia padronizar como você passa e recebe dados do servidor, mas nesse ponto o modelo não pertence realmente ao JavaScript - ele pertence ao seu aplicativo do lado do servidor.

Eu vi uma tentativa há algum tempo em que alguém criou uma estrutura para modelar dados em JavaScript, muito parecido com o modo como o SQLite pertence ao aplicativo.Era como Model.select( "Product" ) e Model.update( "Product", "Some data..." ).Era basicamente uma notação de objeto que continha vários dados para gerenciar o estado da página atual.No entanto, no minuto em que você atualiza, todos os dados são perdidos.Provavelmente estou errado na sintaxe, mas você entendeu.

Se você estiver usando jQuery, a abordagem de Ben é realmente a melhor.Estenda o objeto jQuery com suas funções e propriedades e depois compartimente seus "controladores".Normalmente faço isso colocando-os em arquivos de origem separados e carregando-os seção por seção.Por exemplo, se fosse um site de comércio eletrônico, eu poderia ter um arquivo JS cheio de controladores que controlam a funcionalidade do processo de checkout.Isso tende a manter as coisas leves e fáceis de gerenciar.

Apenas um rápido esclarecimento.

É perfeitamente viável escrever aplicativos GWT que não sejam orientados a servidor.Estou assumindo que de Orientado a Servidor você quer dizer GWT RPC que precisa de back-end baseado em java.

Eu escrevi aplicativos GWT que são muito "MVC" apenas no lado do cliente.

  • O modelo era um gráfico de objeto.Embora você codifique em Java, em tempo de execução os objetos estão em javascript sem necessidade de qualquer JVM no cliente ou no lado do servidor.O GWT também oferece suporte a JSON com suporte completo para análise e manipulação.Você pode se conectar facilmente a webservices JSON, consulte 2 para obter um exemplo de mashup JSON.
  • A visualização era composta por widgets padrão do GWT (além de alguns de nossos próprios widgets compostos)
  • A camada do controlador foi cuidadosamente separada do padrão View via Observer.

Se o seu histórico "fortemente tipado" for Java ou linguagem semelhante, acho que você deveria considerar seriamente o GWT para grandes projetos.Para projetos pequenos eu geralmente prefiro jQuery.Por vir GWTQuery que funciona com o GWT 1.5 pode mudar isso, embora não em um futuro próximo, devido à abundância de plugins para jQuery.

Não tenho 100% de certeza do que você quer dizer aqui, mas direi que depois de usar ASP.NET nos últimos 6 anos, minhas páginas da web agora são dirigidas principalmente por JavaScript, uma vez que a renderização básica da página é feita pelo servidor.Eu uso JSON para tudo (já faz cerca de 3 anos) e uso Kit Mochi para minhas necessidades do lado do cliente.

A propósito, JavaScript é OO, mas como usa herança prototípica, as pessoas não dão crédito dessa forma.Eu também diria que também é funcional, tudo depende de como você o escreve.Se você está realmente interessado em estilos de programação funcional, dê uma olhada Kit Mochi - você pode gostar;ele se inclina bastante para o lado da programação funcional do JavaScript.

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