Best practice: Ajax e scripting lato server con stored procedure

Question

Best practice: Ajax e scripting lato server con stored procedure

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

3

Ho bisogno di ricostruire un vecchio sito web enorme e probabilmente di portare tutto a ASP.NET e jQuery e vorrei chiedere suggerimenti e suggerimenti. In realtà il sito web utilizza:

Ajax (client site with prototype.js)
ASP (vb script server side)
SQL Server 2005
IIS 7 as web server

Questo sito Web utilizza centinaia di stored procedure e le richieste sono fatte da ajax call e solo 1 pagina ASP che contengono un enorme select case

A breve un esempio:

JAVASCRIPT + PROTOTYPE:

var data = {
    action:     'NEWS',
    callback:   'doNews',
    param1:     $('text_example').value,
    ......:     ..........};
AjaxGet(data); // perform a call using another function + prototype

ASP ASP SERVER:

<% ......
select case request("Action")
case "NEWS"
    With cmmDB
        .ActiveConnection = Conn
        .CommandText = "sp_NEWS_TO_CALL_for_example"
        .CommandType = adCmdStoredProc 

        Set par0DB = .CreateParameter("Param1", adVarchar, adParamInput,6)
        Set par1DB = .CreateParameter(".....", adInteger, adParamInput)
        ' ........ ' can be more parameters

        .Parameters.Append par0DB
        .Parameters.Append par1DB

        par0DB.Value = request("Param1")
        par1DB.Value = request(".....")

        set rs=cmmDB.execute

        RecodsetToJSON rs, jsa ' create JSON response using a sub
    End With
.... %>

Quindi come puoi vedere ho una pagina ASP che ha un lotto di CASE e questa pagina risponde a tutte le richieste Ajax nel sito.

La mia domanda è:

Invece di avere molti CASES è possibile creare il codice vb dinamico che analizza la richiesta ajax e crea dinamicamente la chiamata all'SP desiderato (implementando anche i parametri passati da JS)?
Qual è l'approccio migliore per gestire situazioni come questa, utilizzando i vantaggi di .Net + protoype or jQuery ?
In che modo i grandi siti gestiscono una situazione come questa? Lo fanno creando 1 pagina per richiesta?

Grazie in anticipo per suggerimenti, indicazioni e suggerimenti.

asp.net sql-server jquery prototyping asp-classic

posta Luka Milani 17.07.2012 - 17:17

fonte

3 risposte

Leggi altre domande sui tag asp.net sql-server jquery prototyping asp-classic

Quando si utilizza DI e opzionalmente un framework IoC un passo troppo lungo? Mapping di memoria fisica diretta di Windows

score 2 · Answer 1

La cosa migliore da fare è dimenticare completamente le procedure memorizzate e creare un'app .net compatibile. Lo dico in questo modo perché non ho familiarità con .NET, ma è un eccellente framework web ed è progettato attorno a ciò che è vagamente noto come una struttura MVC.

In MVC si separa la logica in tre componenti distinti. La vista che gestisce viene visualizzata come HTML / CSS. L'AJAX sfuma un po 'questo, ma le richieste AJAX stesse dovrebbero anche seguire una struttura MVC. Il controller è dove vengono inviate le richieste. Un controllore dovrebbe gestire una richiesta distinta (cioè richiesta di pagina). È qui che il tuo sito attuale utilizza un singolo punto di accesso che è molto complesso. Il framework MVC avrà un componente router che indirizza le richieste al rispettivo controller. L'ultima parte è il modello o il database. Saranno le classi ad essere associate al tuo database. Le query saranno incorporate come metodi nel modello o nel controller o in una combinazione di entrambi (i binari utilizzano una combinazione di entrambi).

Dovresti mettere qualcosa in una stored procedure solo se è particolarmente complessa (cosa che spesso può essere ancora fatta nel modello), o ha bisogno di fare una gestione speciale nei trigger db like ecc. Ho scritto un web estremamente complesso app e hanno utilizzato stored procedure solo in una di esse, e in tal caso è stato implementato un metodo di sicurezza dei dati legacy.

Hai molto lavoro davanti a te dal momento che probabilmente il database non è stato progettato attorno a questo stile. Non abbiate paura di creare viste per correggere alcuni casi in cui il database non viene mappato in modo pulito sui vostri modelli. Se riesci a rimuoverlo, potrebbe essere necessario riprogettare il database con una migrazione verso il nuovo modello. Dipenderà dal tuo piano di cutover e se hai altri sistemi che accedono al database. La vista inversa potrebbe aiutarti anche in questo. In quel caso costruisci le tue nuove tabelle e fai una vista per le app legacy.

Mi spiace di essere stato così a lungo.

score 1 · Answer 2

Instead to have many CASES is possible to create dynamic vb code that parse the ajax request and create dynamically the call to the desired SP (also implementing the parameters passed by JS)?

Sì, il parametro "azione" dovrebbe contenere solo il nome dell'SP. Quindi puoi eliminare tutte le centinaia di casi di switch e if.

Or what is the best approach to handle situation like this, by using the advantages of .Net + protoype or jQuery ?

Non hai nemmeno bisogno di tutte quelle librerie, ho implementato la stessa identica cosa con solo poche righe di JS e un singolo gestore generico di ashx. Il miglior approccio dipende dalle tue esigenze.

How the big sites handle situation like this ? by creating 1 page for request ?

Ciascun "grande sito" ha implementato la propria soluzione in base alle proprie esigenze specifiche.

score 1 · Answer 3

Complessivamente, penso che questa domanda sia troppo generica per avere una "risposta", ma qui c'è la mia "opinione" come un primo sforzo che non riflette nemmeno un grande approccio.

Vedo che questo post è un po 'vecchio, quindi spero che l'OP abbia ottenuto un po' più di ASP.NET e un'esperienza di programmazione orientata agli oggetti. Con ciò, consiglierei di dimenticare le procedure memorizzate per un po 'e concentrarsi inizialmente sull'aggiunta di principi OOP all'applicazione web. Partendo dal presupposto che l'uso di ajax sia necessario, direi che l'approccio esistente può essere recuperato e promuovere ufficialmente l'uso della pagina ASP di analisi come un "motore" implementato come servizio (si pensi al servizio web / WCF). Forse il servizio è responsabile per l'analisi o delega l'analisi a una stored procedure oa un oggetto .NET; entrambi hanno i loro pro e contro: l'aggiornamento della logica di analisi in una procedura memorizzata non richiederebbe la ricompilazione / distribuzione dell'applicazione e potrebbe essere delegato a un DBA (che potrebbe ottimizzare ulteriormente la routine), tuttavia, l'archiviazione della logica nel codice sarebbe meglio adatta al controllo delle versioni i requisiti dell'applicazione come il parser e il codice che utilizza il parser sono probabilmente memorizzati insieme.