Il lavoro programmatore - come essere media: uso di Edge(.js)

Da Ted Neward | Maggio 2016

Ted Neward Bentornato, "MEANers". Nella dispensa precedente, ho aggiunto una sorta di struttura per l'ambiente in caso contrario structureless di JavaScript, nodo e MongoDB, aggiungendo la libreria MongooseJS allo stack di software che ho lentamente compilazione. Di conseguenza alcune "schema" per le diverse raccolte ricezione e l'archiviazione, il middleware nodo/Express, che è utile perché consente di evitare alcuni errori umani ispirato comuni (ad esempio, la ricerca di "fristName" anziché il campo effettivo "firstName"). Soprattutto, MongooseJS è interamente codice sul lato, vale a dire che per scopi pratici, si disporrà di meglio, almeno per quanto riguarda il database è: "schema" del database (rendendo molto più semplice eseguire il refactoring) e "schemaful" nel codice (rendendola molto meno probabile che un errore di digitazione verrà vanificare cose).

Tuttavia, se è possibile portare avanti personali qui, devo ammettere che perdo Microsoft .NET Framework. In alternativa, per essere più specifici, perdo alcuni aspetti molto interessanti che l'ecosistema .NET è disponibili al suo interno. In particolare, eseguendo nel cloud di Microsoft Azure, in cui numerose organizzazioni includerà un investimento di piccole dimensioni (o molto grande) in .NET "stack", sembra un po' fuori luogo essere discorso tanto su JavaScript, se tutti di tale materiale .NET rimane da raggiungere. In alternativa, almeno, irrealizzabili ad eccezione di qualche tipo di richiesta di tipo HTTP lunga esecuzione, che sembra dire il vero quando si sta operando all'interno dello stesso Data Center.

Fortunatamente, abbiamo un bordo. O, in modo più specifico, Edge.js.

Edge.js

Il progetto Edge.js è seriamente uno-di-un tipo qualsiasi in molti modi, in particolare che mira a indirizzo molto direttamente il divario"piattaforma" tra .NET e Node. js. Ospitato in bit.ly/1W7xJmo, Edge.js deliberatamente tenta di rendere disponibili a altro ogni piattaforma in modo molto intuitivi per ognuno.

Ad esempio, ottenere un esempio di codice Node. js per chiamare una funzione .NET presenta un aspetto simile al seguente:

var edge = require('edge');
var helloWorld = edge.func(function () {/*
  async (input) => {
    return ".NET Welcomes " + input.ToString();
  }
*/});
helloWorld('JavaScript', function (error, result) {
  if (error) throw error;
  console.log(result);
});

Come si può vedere, a livello di codice, questo non è difficile: Passa una funzione di valore letterale per il metodo edge.func e all'interno di tale funzione letterale includono il codice .NET per richiamare come corpo di un commento.

Sì, lettori, un commento. Non è in modo anomalo quando ci si accorge:

Non può essere letterale sintassi c# o l'interprete di nodo non riconosciuto come sintassi programma legittimo (perché, dopo tutto, l'interprete di nodo è un interprete JavaScript, non un interprete c#).
A differenza di un programma compilato, l'interprete ha accesso al corpo completo di qualsiasi codice sorgente è definito, anziché solo ciò che il compilatore ha scelto di generare.

Notare che questo non è limitato al solo c#, l'altro; il progetto Edge.js Elenca varie altre lingue che possono essere utilizzati come "destinazione" di una chiamata di bordo, tra cui F #, Windows PowerShell, Python o persino Lisp, utilizzando le implementazioni .NET di ognuno di questi linguaggi. Il mio preferito è certamente F #:

var edge = require('edge');
var helloFs = edge.func('fs', function () {/*
  fun input -> async {
    return "F# welcomes " + input.ToString()
  }
*/});
helloFs('Node.js', function (error, result) {
  if (error) throw error;
  console.log(result);
});

Si noti che la differenza principale è un argomento ignorato davanti la funzione letterale, che indica quale lingua è passato in commento tale funzione.

La chiave qui è bene tenere presente che il corpo della funzione, ovvero se scritta in c# o in F #, è di un oggetto specifico. Firma dei tipi di rete: Func < oggetto, l'attività < oggetto >>. La modalità asincrona in questo caso è necessaria perché si tenga presente che nodo preferito callback per indicare l'esecuzione sequenziale per evitare di bloccare il ciclo di eventi di Node. js principale.

Edge.js rende relativamente semplice richiamare le funzioni nella DLL di .NET compilate. Quindi, ad esempio, se si dispone di un assembly compilato del codice .NET che deve essere richiamato, Edge.js possibile richiamarlo purché il nome dell'assembly, nome del tipo e il nome di metodo vengono forniti come parte della chiamata "func":

var helloDll = edge.func({
  assemblyFile: "Echo.dll",
  typeName: "Example.Greetings",
  methodName: "Greet"
});

Se la firma dei tipi di Greet è Func < oggetto, l'attività < oggetto >>, come quella illustrata Figura 1, può chiamare utilizzando lo stesso modello di chiamata (passando un callback di funzione e gli argomenti di input), come illustrato per altri esempi di Node. js.

Figura 1, un Endpoint compatibile con Edge.js .NET

using System;
using System.Threading.Tasks;
namespace Example
{
  public class Greetings
  {
    public async Task<object> Greet(object input)
    {
      string message = (string)input;
      return String.Format("On {0}, you said {1}",
        System.DateTime.Now,
        Message);
    }
  }
}

È inoltre possibile eseguire l'altro modo, per disporre di codice .NET per chiamare in pacchetti di Node. js, ma poiché l'obiettivo consiste nell'utilizzare Node. js sul lato server, sarà trattato come un esercizio al lettore interessati. (A proposito, sono molto più semplici da utilizzare da una macchina Windows rispetto a un Mac tutti i dati visualizzati Edge.js; tentando di ottenerla da utilizzare durante la scrittura di questo articolo il Mac è stato decisamente troppo lunga, tutto ciò, questo è un caso in cui esperienza Windows senz'altro è prioritaria rispetto alle Mac per lo sviluppo di Node. js.)

Si desidera assegnare questo una selezione di hello world-stile veloce prima di eseguire qualsiasi operazione più complessa.

Ciao, bordo

Prima di tutto, anche in questo caso, tutto questo deve prima di lavorare in Microsoft Azure (perché è l'ambiente di distribuzione di destinazione scelta), pertanto assicurarsi di "npm install - Salva edge" in modo che verranno registrato nel file manifesto del package. JSON quando viene eseguito il commit in Azure. Successivamente, aggiungere la funzione "helloWorld" per il codice di App. js e un rapido endpoint in modo che "Devo" su di esso e ottenere il messaggio introduttivo tramite HTTP, come illustrato nel Figura 2. E, naturalmente, l'invio di una richiesta GET a msdn-mean.azurewebsites.net/edgehello riporta:

{"message":".NET Welcomes Node, JavaScript, and Express"}

Figura 2 aggiunta "helloWorld" (funzione)

var helloWorld = edge.func(function () {/*
    async (input) => {
        return ".NET Welcomes " + input.ToString();
    }
*/});
var edgehello = function(req, res) {
  helloWorld('Node, JavaScript, and Express', function (err, result) {
    if (err) res.status(500).jsonp(err);
    else res.status(200).jsonp( { message: result } );
  });
};
// ...
app.get('/edgehello', edgehello);

Ciao, SQL Server

Una domanda che si verifica periodicamente ogni volta che questo intervento vengono spiegati la media dello stack con gli sviluppatori .NET riguarda MongoDB. Un notevole numero di persone non piace l'idea di rinunciare di SQL Server, in particolare durante l'esecuzione in Azure. Naturalmente, la community di Node. js ha creato l'accesso ai database relazionali diverse API e SQL Server è solo una connessione TDS lontano da uno di questi, ma Edge.js è effettivamente una soluzione molto utili per il problema specifico (una volta a è "npm install - Salva edge-sql," per inserire il pacchetto SQL Edge):

var edge = require('edge');
var getTop10Products = edge.func('sql', function () {/*
  select top 10 * from Products
*/});
getTop10Products(null, function (error, result) {
  if (error) throw error;
  console.log(result);
  console.log(result[0].ProductName);
  console.log(result[1].ReorderLevel);
});

Questo codice si presume che l'ambiente Azure è una variabile di ambiente denominata EDGE_SQL_CONNECTION_STRING impostato sulla stringa di connessione SQL Server appropriata (ovvero, in questo caso, sarebbe probabilmente punti all'istanza di SQL Server in esecuzione in Azure).

Che è probabilmente più semplice rispetto all'utilizzo con qualsiasi altro che ho visto, per essere onesti. Probabilmente non verrà sostituito Entity Framework nel prossimo futuro, concesse, ma per accedere rapidamente a un'istanza di SQL Server, come parte di un approccio di "polypraeclusio" ("archiviazione più") che utilizza SQL Server per archiviare l'esclusivamente i dati relazionali schemaed e MongoDB per i dati JSON ICA senza schema, è effettivamente molto elegante.

Per quale motivo nuovamente?

Dato che gli sviluppatori in genere un aspetto askance qualsiasi soluzione che è necessario avere familiarità in più lingue contemporaneamente, è probabilmente la pena approfondimenti leggermente in quando e come possono essere usato.

La risposta più ovvia è che per la maggior parte dei tipi greenfield dei progetti, senza codice legacy di supporto necessario, la regola generale sarebbe rimanere interamente all'interno di un linguaggio/piattaforma o l'altro: adattarsi con .NET e utilizzare API Web e così via, o "intero hog" seleziono Node. js e si basano su diverse librerie e pacchetti trovati lì per raggiungere gli obiettivi in questione. Dopo tutto, per qualsiasi cosa che è possibile considerare questa parte del mondo .NET, è probabile che un pacchetto equivalente nel repository del pacchetto npm. Tuttavia, questo approccio viene fornito con alcune considerazioni.

In primo luogo, l'ecosistema .NET ha il vantaggio di essere stata molto più intorno e, pertanto, in parte dei pacchetti sono più comprovata e attendibile. Molti dei pacchetti npm sono ancora flirting con numeri di versione elevata ambigui; responsabili hanno difficoltà a qualsiasi elemento attendibili con un numero di versione inizia con 0, ad esempio.

In secondo luogo, alcuni problemi si prestano meglio ad alcuni approcci di programmazione o ambienti; Nella fattispecie, il linguaggio F # spesso "ha più senso" a quelli con uno sfondo matematico e rende più semplice talvolta di scrivere alcuni tipi di codice. Ad esempio avveniva pochi anni fa quando ho scritto la libreria Feliza (come parte della serie che illustra l'utilizzo di SMS nel cloud tramite il cloud Tropo); mentre potrebbe essere stato scritto in c#, F # di corrispondenza e "modelli attivi" reso molto più semplice cui avevo in c#. Lo stesso vale per JavaScript (forse più).

Ultima e, forse più importante è che talvolta l'ambiente in cui viene eseguito il codice appena naturalmente predilige una piattaforma rispetto a un altro. Ad esempio, numerose organizzazioni che ospitano applicazioni in Azure utilizzano Active Directory come l'autenticazione e autorizzazione di base; verrà di conseguenza, desiderano continuare a utilizzare Active Directory per le nuove applicazioni scritte, in .NET o Node. js. Accesso ad Active Directory è in genere molto più semplice e più semplice per farlo da un ambiente .NET rispetto a qualsiasi altro, la libreria Edge.js offre un comodo "trap sportello," per così dire, affinché sia molto più semplice accedere ad Active Directory.

Avvolgendo

È stato un po' più chiaro affrontare, soprattutto perché la libreria Edge.js ha molto del lavoro fuori uso interoperably con l'ambiente .NET. E offre un'ampia gamma di nuove opzioni per Azure efficiente, poiché ora è possibile accedere a una singola ma due ecosistemi avanzati, completi di strumenti, librerie e pacchetti.

Si noti che esiste un'intera colonna in attesa di essere scritti sarà nella direzione opposta, anche l'altro: In molti casi, alcuni tipi di applicazioni sono molto più facile da scrivere utilizzando i vari pacchetti disponibili nel repository npm, che Edge.js ora visualizzata per gli sviluppatori di .NET tradizionali. E con la versione di origine aperti di recente di Chakra: la base di Microsoft JavaScript che è possibile "collegare" nell'ambiente di nodo come plug-in più, viene visualizzata anche altre opportunità di utilizzare JavaScript come parte di un'applicazione .NET "standard", tra cui anche la possibilità di ospitare un interprete JavaScript al centro dell'applicazione. Questo ha un proprio implicazioni interessanti quando si arresta non.

Esistono alcuni aspetti da discutere prima di passare completamente fuori del server, ma sono di spazio, per ora... buona codifica!

Ted Newardè un consulente polytechnology basato su Seattle, relatore e mentore. Ha scritto oltre 100 articoli, è un MVP c#, relatore di INETA, ha creato e coautore di numerosi libri. Contattarlo all'indirizzo ted@tedneward.com se si è interessati a far lui provenire collaborano con il team o leggere il suo blog all'indirizzo blogs.tedneward.com.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Shawn Wildermuth

Condividi tramite