App Web a più livelli che utilizza i servizi Web JQuery / ASP.NET

3

Per applicazioni Web di piccole dimensioni e non complesse, abbiamo utilizzato jQuery per effettuare chiamate asincrone a un servizio Web ASP.NET per l'interazione con il nostro archivio dati Sqlite. Questo ha dimostrato di essere un modo abbastanza pulito per isolare i livelli delle applicazioni sfruttando al contempo la potente funzionalità lato client di JQuery.

Tuttavia, al momento stiamo progettando un'applicazione più grande costituita da potenzialmente centinaia di elementi di dati. Sono preoccupato dal fatto che il tipo di architettura sopra menzionato potrebbe diventare abbastanza veloce se stiamo passando centinaia di elementi nel servizio web da un post jQuery ajax.

Mi interessava l'esperienza degli altri con questo tipo di design e se avresti raccomandato un altro approccio.

    
posta kittyhawk 22.07.2011 - 16:50
fonte

2 risposte

1

Sulla base delle informazioni che hai fornito, penso che le persone possano solo consigliare, non fornire un'architettura:

  1. Prova a racchiudere la funzionalità jQuery, in particolare la parte ajax, perché potresti voler creare una posizione centralizzata per fare qualcosa in un secondo momento nel tuo progetto (ad esempio, implementare il reindirizzamento lato client alla pagina di accesso sulle chiamate ajax, che è comunemente nota come gestione delle sessioni con ajax)
  2. Evita i metodi di pagina e rimani con i servizi web. Lo scopo principale dei metodi Page è che si tratta di servizi web in miniatura, mirati alla pagina. Ma nelle grandi applicazioni, prima o poi, hai bisogno di quel metodo anche in un'altra pagina. Quindi, cerca di utilizzare i servizi web il più possibile.
  3. Uno dei maggiori problemi delle applicazioni web di grandi dimensioni è che sono gonfiati da decine di librerie client-side. Hai bisogno di un editore HTML, aggiungi molte librerie. È necessario il caricamento lazy di JavaScript, si aggiungono le librerie. Hai bisogno di test delle unità in JavaScript, aggiungi librerie e così via e così via. Nei progetti di piccole dimensioni, le persone accettano di includere ogni libreria in una pagina principale, anche se non è utilizzata in una pagina derivata. Tuttavia, in applicazioni di grandi dimensioni, è possibile riscontrare un punto in cui sono presenti 20 librerie js su una pagina, da cui si utilizza solo jQuery. Devi affrontare questo problema regolarmente.
  4. Un altro problema che ho riscontrato personalmente sono i percorsi (URL) dei tuoi servizi Web in JavaScript . Possono diventare un mal di testa quando si riorganizza semplicemente la struttura del file system del progetto man mano che diventa sempre più grande. Raccomando di passare a MVC (in modo da ottenere l'URL delle azioni tramite il metodo Url.Action ) o semplicemente creare una sorta di classe di utilità PathBuilder per generare l'URL di un servizio Web basato su alcuni parametri.

L'architettura del server sembra non essere stata toccata più di tanto con i progetti più grandi.

    
risposta data 09.09.2011 - 06:48
fonte
0

Consiglio vivamente di passare a YUI e di sfruttare la potente gestione degli eventi. Puoi costruire ogni elemento della pagina come un widget univoco e ognuno può sottoscrivere gli eventi creati e attivati (ad esempio: _on_validate_request, _on_validate_request_response, _on_before_submit).

YUI è molto più prolisso di jQuery, ma gli eventi ne valgono la pena per l'interfaccia utente Web complicata / avanzata.

    
risposta data 09.08.2011 - 22:55
fonte