Refatorando o código de espaguete jQuery para usar DDD [closed]

5

A maior parte do meu código do lado do cliente acaba como um script longo em um arquivo, o mais parecido com isto:

<script>
function someFunction1(){/*...*/}
function someFunction2(){/*...*/}
...
var globalVariable1;
var globalVariable2;
...
$(function(){

$('selector1').click(function(){
    //get relevant data from various DOM elements

    //some business logic rules and validation

    //open dialog box

    //more business logic rules and more validation

    //post an ajax request

    //update the DOM    
});

//many other events

//many jQuery dialogs    
});
</script>

É um pesadelo de manutenção. Embora eu use uma estrutura do lado do servidor bem projetada usando DDD (serviços de aplicativos, sevices de domínio, objetos de valor, etc ...). Eu tive pouca sorte de estruturar meu código de cliente para uma melhor separação de interesses.

Não estou criando um aplicativo do lado do cliente. Eu apenas uso o jQuery intensivamente para o lado do cliente.

Como devo abordar a estrutura de código para aplicar DDD no lado do cliente?

    
por Songo 09.09.2013 / 11:42
fonte

4 respostas

1

Parece que você poderia usar um framework MVVM (AngularJS, Knockout, ...), quando você inclui o jQuery junto com o AngularJS ele usará o jQuery em vez do jQLite que o AngularJS tem, então você ainda tem o jQuery.

O que esse tipo de framework permite fazer é definir ações nos elementos referentes aos métodos do controlador. Por exemplo, o AngularSJ possui a diretiva ng-click; Isso ao invés de selecionar algo com jQuery e depois adicionar um manipulador de eventos)

O AngularJS também permite que você separe seu código em controladores, serviços, configurações, etc. (Eu estou apenas me referindo ao AngularJS aqui porque eu não trabalhei com o Knockout ou qualquer um dos outros.)

    
por 09.09.2013 / 12:01
fonte
1

I'm not building a client-side application. I just use jQuery intensively for the client side.

Se o seu objetivo for refatoração gradual em vez de uma reescrita, confira RequireJS , que (ao contrário de todas as outras respostas) é não um framework MVC.

Em vez disso, é apenas uma maneira de dividir seu código em módulos e lidar com as dependências entre eles. O mecanismo para isso é chamado de "Assynchronous Module Definition", ou AMD, que se assemelha um pouco à maneira como as classes em PHP ou Java são tipicamente organizadas.

Aqui está um exemplo ridiculamente simples:

myapp / quoteList.js

// Define a module with no dependencies that is an array
define([],function(){
    return(["Hello","World"]);
});

myapp / generateQuote.js

// Define a module with one dependency on another module and is a function
define(["./quoteList"],function(quoteList){
    var f = function(){
        var num = Math.floor(Math.random() * quotes.length);
        return quotes[num];
    };
    return f;
});

myapp / MyUtils.js

// Define a module which is an object. (Effectively a singleton)
define(["./generateQuote"],function(quotes){
    var o = {
        "getQuote" : generateQuote,
        "doPopup" : function(msg){alert(msg);}
    };
    return o;
});

page.html

<script>
// Load a module for use by plain old procedural code
require(["myapp/MyUtils"],function(MyUtils){
    MyUtils.doPopup(MyUtils.getQuote());
});
</script>

Dessa forma, você pode começar a dividir seu código existente em qualquer organização que faça mais sentido para você.

    
por 27.09.2013 / 03:53
fonte
0

Recomendaria enfaticamente usar algum tipo de estrutura JavaScript MV *. Há muitos deles (AngularJS, KnockoutJS, Ember, Backbone). Aqui é uma boa revisão de alguns dos mais populares queridos.

Usar um framework JS às vezes pode ser um exagero para algumas páginas simples sem muita interatividade ou se as páginas dependem muito do lado do servidor. Nesses casos, o framework JS provavelmente não seria um bom ajuste. Mas se você está construindo algo que é mais complexo (no lado do cliente) e requer alguma interatividade (como manipulação ou roteamento DOM freqüente), o framework JavaScript é uma solução perfeita.

Com estruturas do lado do cliente, você tem metade do trabalho feito para você:

  • Modelos que representarão seus dados.
  • Exibições que serão atualizadas quando você alterar seus modelos.
  • Controladores que manipulam a entrada do usuário (e modificam seus modelos).

A maioria das estruturas MV * também suportam testes de unidade e testes de ponta a ponta (adoro a maneira como o teste é suportado no AngularJS). Os testes de unidade no front-end garantirão que sua funcionalidade não seja interrompida quando alguém alterar alguma coisa (por exemplo, alguma classe foi removida ou alterada e seu seletor de jQuery não pode encontrar o elemento para adicionar click event handler).

    
por 09.09.2013 / 12:23
fonte
0

Você pode criar seu próprio MVC se seu site for bem básico. Dê uma olhada no PureMVC e tente emular esse modelo. Obter um sistema de pub / sub, como rádio, em seguida, construir isso: Uma fachada que registra todos os mediadores, controladores e modelos. Dado que você sabe quais são os dois últimos, o mediador é basicamente o componente view / view - mas ele abstrai para que você não tenha que se preocupar com o html subjacente. Os mediadores recebem e enviam mensagens. Muitas vezes, eles podem receber mensagens do modelo bruto, desde que o pedaço de dados não seja muito grande. Outras vezes você precisará de um controlador para gerenciar as coisas. Os controladores são sem estado e entram em ação em uma determinada mensagem. Eles gerenciam a troca entre o modelo e a visão. Se você fizer tudo certo, os controladores são os mais descartáveis quanto à reutilização. Os outros dois são tão burros quanto possível.

    
por 26.09.2013 / 23:06
fonte