Logica aziendale JavaScript lato client nello stack di soluzioni Net

Scrivo questo dal punto di vista di uno sviluppatore di lunga data di .NET che viene trascinato inesorabilmente nel mondo JavaScript del lato client, quindi presumo che probabilmente condivido alcuni degli stessi pregiudizi che hai. Ne parlo solo perché penso che molti dei tuoi punti elenco siano probabilmente influenzati dalla tua esperienza e dal relativo comfort con C # e .NET su JavaScript.

Ad esempio:

1. Testing: While we can leverage testing frameworks such as Jasmine the level of effort involved with developing and integrating these types of test scripts is substantial compared to the TDD approach used with other back-end .Net development methodologies.

Questo viene contestato quotidianamente dalla comunità JavaScript. C'è una quantità significativa di sforzo che va in un corretto approccio .NET TDD che penso tu stia facendo una riflessione qui. Sicuramente non più del sempre migliore framework di test JavaScript. Ma, presumibilmente più familiarità con gli strumenti e le pratiche relative a .NET, sembra che la vera fonte di apprendimento sia l'adozione di nuovi strumenti e pratiche relativi a JavaScript. Questa è una preoccupazione valida, ma non proprio uguale a ".NET è migliore".

2. Debugging and Development: Similar to my testing argument; most mainstream browsers have great development and debugging plugins that make development far less frustrating and enjoyable today. However, these still do lack the richness in capability and ease of use when debugging domain/business objects on the back-end within Visual Studio.

È difficile argomentare contro le ricche funzionalità di debug di Visual Studio, quindi non lo farò. :-)

Tuttavia, direi che nella stragrande maggioranza del tempo (nella mia esperienza) viene utilizzato solo un piccolo sottoinsieme delle funzionalità di debug di VS. La maggior parte di ciò che accade nel debugger passa attraverso il codice da breakpoint a breakpoint, controllando il flusso e lo stato lungo il percorso. Si potrebbe sostenere che questo può essere fatto altrettanto bene nel codice JavaScript (ben progettato) sul client, come può nel codice C # sul server. Soprattutto quando si utilizza VS come debugger.

3. Coupling: Domain/Business logic is tightly coupled to JavaScript runtimes. The browser in this case.

Non sono sicuro di essere d'accordo con questo. Il codice JavaScript ben modulare non deve necessariamente essere abbinato al browser. Il codice logico aziendale (al contrario del codice manipolativo DOM) può e deve essere scritto in modo tale che possa essere eseguito e testato senza il browser.

5. Cross-Browser Compatibility: While less of a problem today it does warrant some consideration.

Sono d'accordo. Quando si scrive codice per .NET sul server, si conosce e si controlla quale ambiente runtime viene eseguito il codice in esecuzione. Con JavaScript, potrebbero esserci sottili differenze con alcuni codici tra i diversi motori JS. Mi chiedo quanto possa davvero avere un impatto reale. Ti sei imbattuto in un esempio reale o ipotetico a questo punto?

4. Code Security: This is one is pretty straightforward.

Questo è il grande, per me. E l'interruttore. È semplicemente il caso che il codice in esecuzione nel browser (e non sul server) sia fuori dal tuo controllo, a meno che tu non possa controllare anche il browser. Un'app responsabile dovrebbe ricontrollare tutte le logiche di business eseguite sul client, poiché l'integrità del client non dovrebbe essere considerata attendibile. Questo mi sembrerebbe di portare a un sacco di codice duplicato o di un'app inaffidabile. Ciò è meno preoccupante per un'app aziendale interna solo che con un sito aperto al pubblico, ma dovrebbe comunque essere comunque una preoccupazione.

Tutto questo è per dire che, se fossi nella tua squadra, sarei d'accordo con te. :-) Ma non per le ragioni che hai fornito, il che non sarebbe molto convincente per qualcuno desideroso di abbracciare JavaScript e la programmazione lato client. E quegli argomenti si indeboliscono di giorno in giorno.

Penso che molti dei tuoi punti principali siano abbastanza fuorvianti; affermando che "sì i browser possono farlo, ma Visual Studio è migliore" non convincerà i tuoi colleghi (che probabilmente sono più abituati a eseguire il debug di JS piuttosto che lavorare con VS). Inoltre:

• numero 3 non è un problema reale; puoi scrivere JS che non fa affidamento sulla versione del browser e che non significa più restrizioni che potresti avere scrivendo in C # (in effetti si potrebbe sostenere che ti stai limitando di più usando C # / CLR, dato che puoi eseguire JS sul tuo server).

• il numero 5 è anche privo di senso; anche storicamente, la maggior parte dei problemi relativi ai browser incrociati sono stati messi in relazione con l'implementazione del DOM (come accedere a un modulo, campo di input, quali proprietà di supporto, ecc.) rispetto allo stesso JS. Un JS ben scritto non dovrebbe avere problemi.

Il fattore principale è che, come sempre, non ti puoi fidare del cliente . A meno che il risultato della logica di business non venga prodotto solo per quell'utilizzo da parte del cliente, non puoi implementarlo perché non puoi essere sicuro che quel risultato provenga dalla tua logica o da altro software che afferma di essere la tua logica.

Immagina che la tua banca abbia lavorato così; quando hai effettuato l'accesso invierebbe al tuo browser lo stato dei tuoi account al tuo ultimo accesso e l'elenco delle transazioni verificatesi, in modo che il browser calcoli l'importo corrente nei tuoi account e invii i dati alla banca (chi lo memorizzerebbe nel loro DB). Suona bene? Forse qualcuno cercherebbe di trarre profitto da questa architettura?

Anche in uno schema in cui le persone non trarrebbero profitto, come SETI @ home ¹ , alcune persone hanno "hackerato" il programma legit solo per migliorare le proprie statistiche. Se qualcuno trarrebbe beneficio dal fornire al tuo sistema risultati aziendali falsi, a un certo punto qualcuno proverà. Spostare la logica di business nel browser lo rende incredibilmente facile da fare.

Inoltre, spostare la logica al cliente di solito significa che i dati saranno più difficili da proteggere, poiché sarà necessario consentire l'accesso a quasi tutto al browser in modo che possa elaborare la logica di business. Ottenere la granularità che consente l'accesso a tutto ciò che è necessario, ma non un po 'di più, sarà molto impegnativo.

¹ : nel caso in cui non ricordi, SETI @ Home era un programma che hai installato nel tuo computer per elaborare i dati da un radiotelescopio nel suo tempo libero; nella speranza di trovare un segnale inviato da una forma di vita extraterrena.