Refactoring codice jQuery spaghetti per usare DDD [chiuso]

Question

Refactoring codice jQuery spaghetti per usare DDD [chiuso]

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

5

La maggior parte del mio codice lato client finisce come uno script lungo in un file, per lo più simile a questo:

<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>

È un incubo di manutenzione. Sebbene io usi una struttura lato server ben progettata che usa DDD (servizi applicativi, sevizi di dominio, oggetti valore, ... ecc.) Ho avuto poca fortuna a strutturare il mio codice cliente per una migliore separazione delle preoccupazioni.

Non sto costruendo un'applicazione client-side. Io uso solo jQuery intensivamente per il lato client.

Come dovrei approcciare la struttura del codice per applicare DDD lato client wide?

design domain-driven-design javascript design-patterns client-side

posta Songo 09.09.2013 - 11:42

fonte

4 risposte

Leggi altre domande sui tag design domain-driven-design javascript design-patterns client-side

Come posso implementare una funzione di "salvataggio" modulare per un gioco? Ho ragione di essere scettico su ASP.NET MVC "Html Helpers"? [chiuso]

score 1 · Answer 1

Sembra che tu possa usare un framework MVVM (AngularJS, Knockout, ...), quando includi jQuery insieme ad AngularJS utilizzerai jQuery al posto del jQLite di cui dispone AngularJS, quindi hai ancora jQuery.

Ciò che questo tipo di framework ti consente di fare è definire le azioni sugli elementi che si riferiscono ai metodi del controller. Ad esempio AngularSJ ha la direttiva ng-click; Questo invece di selezionare qualcosa con jQuery e quindi aggiungere un gestore di eventi)

Anche AngularJS ti consente di separare il tuo codice in controller, servizi, configurazioni, ecc. (Mi riferisco solo ad AngularJS qui perché non ho lavorato con Knockout o con nessuno degli altri.)

score 1 · Answer 2

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

Se il tuo obiettivo è refactoring graduale piuttosto che una riscrittura, verificherei RequireJS , che (a differenza di tutte le altre risposte) è non un framework MVC.

Invece, è solo un modo per suddividere il codice in moduli e gestire le dipendenze tra di loro. Il meccanismo per questo è chiamato "Asynchronous Module Definition", o AMD, che assomiglia in qualche modo al modo in cui le classi in PHP o Java sono in genere organizzate.

Ecco un esempio ridicolmente semplice:

frontend / quoteList.js

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

frontend / 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;
});

frontend / 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>

In questo modo puoi iniziare a inserire il tuo codice esistente in qualsiasi organizzazione che abbia più senso per te.

score 0 · Answer 3

Consiglio vivamente di utilizzare un qualche tipo di framework MV * JavaScript. Ce ne sono molti (AngularJS, KnockoutJS, Ember, Backbone). Qui è una buona recensione di alcuni dei più popolari quelli.

L'utilizzo di un framework JS a volte può essere eccessivo per alcune pagine semplici senza molta interattività o se le pagine dipendono dal lato server. In questi casi, il framework JS non sarebbe probabilmente adatto. Ma se stai costruendo qualcosa che è più complesso (sul lato client) e richiede un po 'di interattività (come la frequente manipolazione o il routing DOM), il framework JavaScript è una soluzione perfetta.

Con i framework lato client hai metà del lavoro fatto per te:

Modelli che rappresenteranno i tuoi dati.
Visualizzazioni che verranno aggiornate man mano che cambi i tuoi modelli.
Controller che gestiscono l'input dell'utente (e modificano i tuoi Modelli).

La maggior parte dei framework MV * supporta anche test delle unità e test end-to-end (adoro il modo in cui i test sono supportati in AngularJS). I test unitari sul front-end garantiranno che le tue funzionalità non si interrompano quando qualcuno cambia qualcosa (ad esempio, alcune classi sono state rimosse o modificate e il tuo selettore jQuery non riesce a trovare l'elemento per aggiungere click gestore di eventi).

score 0 · Answer 4

Puoi pubblicare il tuo MVC se il tuo sito è abbastanza semplice. Dai un'occhiata a PureMVC e prova ad emulare quel modello. Ottieni un pub / sottosistema come radio quindi crea questo: Una facciata che registra tutti i mediatori, i controller e i modelli. Dato che sai quali sono gli ultimi due, il mediatore è fondamentalmente il componente vista / vista, ma lo astrae in modo da non doversi preoccupare dell'html sottostante. I mediatori ricevono e inviano messaggi. Spesso possono ricevere msg dal modello raw, a patto che il blocco dati non sia troppo grande. Altre volte ti servirà un controller per gestire le cose. I controllori sono apolidi e entrano in azione in un determinato messaggio. Gestiscono lo scambio tra il modello e la vista. Se fai tutto bene, i controller sono i più usa e getta fino al riutilizzo. Gli altri due sono il più stupidi possibile.