Mai 2016
Volume 31,numéro 5
Cet article a fait l'objet d'une traduction automatique.
Le travail programmeur - comment être moyenne : Obtenir Edge(.js)
Par Ted Neward | Mai 2016
.jpg "Ted Neward")
Bienvenue, « MEANers ». Dans l'article précédent, j'ai ajouté un peu de structure à l'environnement dans le cas contraire structureless est JavaScript, nœud et MongoDB, en ajoutant la bibliothèque MongooseJS à la pile logicielle que j'ai créé lentement. Ce qui a mis des « schémas » dans les différentes collections de réception et le stockage, le middleware nœud/Express qui est intéressant, car il permet d'éviter certaines erreurs humaines inspiré courantes (par exemple, recherchez « fristName » au lieu du champ « firstName »). De plus, MongooseJS est entièrement code côté, ce qui signifie que pour des raisons pratiques, vous obtenez le meilleur des deux mondes, au moins en ce qui concerne la base de données est: « schéma » dans la base de données (le rend beaucoup plus facile de refactoriser) et « schemaful » dans le code (en moins de risque qu'une faute de frappe sera endommagera choses).
Toutefois, si je peux prendre un moment personnel ici, je dois admettre que je manque de Microsoft .NET Framework. Ou, pour être plus précis, je manque certaines des choses étonnantes que dont dispose l'écosystème .NET qu'il contient. En particulier, lorsque j'exécuterai sur le cloud Microsoft Azure, où un certain nombre d'organisations vont avoir à des investissements small (ou très grande taille) dans le .NET « pile », il semble un peu de place à JavaScript, voir si tous les de qui les choses .NET restent d'atteindre. Ou, au moins, hors de portée à l'exception des quelconque de la demande de type HTTP longue distance, ce qui semble stupide de lorsque vous êtes dans le même centre de données.
Heureusement, nous avons un bord. Ou, pour être plus précis, Edge.js.
Edge.js
Le projet Edge.js est gravement celui de-uniques dans un grand nombre de façons, plus particulièrement il cherche à très directement l'adresse l'intervalle « plate-forme » entre .NET et Node.js. Hébergé sur bit.ly/1W7xJmo, Edge.js délibérément cherche à disposition chaque plateforme à l'autre de façon très faciles à coder à chacun.
Par exemple, obtenir un exemple de code Node.js pour appeler une fonction .NET ressemble à ceci :
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);
});
Comme vous pouvez le voir, par programme, ce n'est pas difficile : Transmettre une fonction littérale à la méthode edge.func et à l'intérieur de cette fonction littérale incluent le code .NET pour appeler le corps d'un commentaire.
Oui, cher lecteur, un commentaire. Ce n'est pas donc étrange lorsque vous réalisez que :
- Il ne peut pas être une syntaxe c# littérale ou l'interpréteur de nœud ne seraient pas reconnaître comme syntaxe de programme légitime (car, après tout, l'interpréteur de nœud est un interpréteur JavaScript, pas un interpréteur c#).
- Contrairement à un programme compilé, l'interpréteur a accès le corps complet de tout code source est défini, au lieu de simplement ce que le compilateur a choisi d'émettre.
Notez que cela n'est pas limité à simplement c#, par ailleurs ; le projet Edge.js répertorie plusieurs autres langages qui peuvent être utilisés comme « cible » d'un appel de bord, y compris les F #, Windows PowerShell, Python ou même Lisp, à l'aide d'implémentations .NET de chacune de ces langues. Mes favoris, bien sûr, est 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);
});
Notez que la différence principale est un argument est passée devant la fonction littérale, indiquant la langue est passée de commentaire de cette fonction.
Ici, c'est à l'esprit que le corps de la fonction, écrit en c# ou en F #, est d'une spécifique. Signature de la NET-type : Func < objet tâche < objet >>. L'asynchronie ici est nécessaire car n'oubliez pas que le nœud préfère rappels pour diriger l'exécution séquentielle afin d'éviter le blocage de la boucle d'événements Node.js principale.
Edge.js facilite relativement facile d'appeler ces fonctions dans des DLL .NET compilées. Ainsi, par exemple, si vous avez un assembly compilé du code .NET qui souhaite appeler, Edge.js peut appeler pour que le nom de l'assembly, le nom de type et le nom de la méthode sont fournis dans le cadre de l'appel de « func » :
var helloDll = edge.func({
assemblyFile: "Echo.dll",
typeName: "Example.Greetings",
methodName: "Greet"
});
Si la signature de type de Greet est une Func < objet tâche < objet >>, tel que celui illustré Figure 1, Node.js peut l'appeler en utilisant le même modèle d'appel (en passant les arguments d'entrée et une fonction de rappel), comme indiqué pour les autres exemples.
Figure 1 un point de terminaison Compatible 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);
}
}
}
Il est également possible de passer l'inverse, pour organiser le code .NET pour appeler les packages Node.js — mais comme l'objectif ici est de travail Node.js côté serveur, je laisse cela comme un exercice pour le lecteur intéressé. (À propos, tous les éléments Edge.js sont beaucoup plus facile à utiliser à partir d'un ordinateur Windows à un Mac ; tentative pour qu'il fonctionne sur mon Mac pendant l'écriture de cette colonne est sans aucun doute trop de temps, tout bien considéré, c'est un cas où Windows expérience sans aucun doute mettre en place une Mac pour le développement Node.js liées.)
Je souhaite à présent une rotation hello world-style rapide avant d'aller plus compliqué.
Bonjour, Edge
Premièrement, là encore, tout cela doit tout d'abord fonctionnent dans Microsoft Azure (car c'est mon environnement de déploiement cible choisi), veillez à « npm install--enregistrer edge » afin qu'allez être suivi dans le manifeste package.json lorsqu'il atteint validée dans Azure. Ensuite, ajoutez la fonction de « helloWorld » dans le code app.js et un point de terminaison rapide afin que je peux « GET » dessus d'obtenir ce message d'accueil par le biais de HTTP, comme indiqué dans Figure 2. Et, bien sûr, l'envoi d'une opération GET pour msdn-mean.azurewebsites.net/edgehello ramène :
{"message":".NET Welcomes Node, JavaScript, and Express"}
Figure 2 Ajout « helloWorld » (fonction)
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);
Bonjour, SQL Server
Une question qui survient périodiquement chaque fois que j'aborderai la moyenne est de pile avec les développeurs .NET sur MongoDB. Un certain nombre de personnes n'aime pas l'idée de donner leur SQL Server, en particulier lors de l'exécution sur Azure. Bien sûr, la Communauté Node.js intègre plusieurs API d'accès de base de données relationnelle et SQL Server est une seule connexion TDS en dehors de celles, mais Edge.js a en fait une solution assez fascinante à ce problème particulier (une fois que vous « npm install--enregistrer edge-sql, » d'extraire le package 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);
});
Ce code suppose que l'environnement Azure a une variable d'environnement appelée EDGE_SQL_CONNECTION_STRING défini sur la chaîne de connexion SQL Server appropriée (qui, dans ce cas, sans doute pointerait vers l'instance de SQL Server s'exécutant dans Azure).
C'est sans doute plus simple qu'avec n'importe quoi autre que j'ai vu, à vrai dire. Il ne remplacerez probablement pas Entity Framework de si tôt, certes, mais pour un accès rapide à une instance de SQL Server, dans le cadre d'une approche « polypraeclusio » (plusieurs « stockage ») qui utilise SQL Server pour le stockage schemaed strictement les données relationnelles et MongoDB pour les données qui JSON sans schéma, il peut en fait très élégante.
Pourquoi, là encore ?
Étant donné que la plupart des développeurs examinent généralement askance une solution qui en a besoin pour être parfaitement dans plusieurs langues en même temps, il vaut sans doute plus en profondeur un peu en lorsque et comment il peut être utilisé.
La réponse la plus évidente est que pour la plupart des types de nouveau des projets, sans prise en charge du code hérité requis, la règle générale est de rester entièrement à l'intérieur d'une langue/plateforme ou l'autre : soit lier avec .NET et utiliser l'API Web et ainsi de suite, ou faire le « ensemble hog » Node.js et s'appuient sur les diverses bibliothèques et les packages qui se trouvent afin d'atteindre les objectifs à portée de main. Après tout, pour n'importe quoi que vous pouvez vous représenter dans le monde de .NET, il existe probablement un package équivalent dans le référentiel de package npm. Toutefois, cette approche présente quelques inconvénients.
Tout d'abord, l'écosystème .NET présente l'avantage d'avoir été beaucoup plus autour et, par conséquent, certains packages il plus éprouvés et fiable. Nombre des packages npm sont toujours flirting avec les numéros de version hautement douteuse ; gestionnaires est difficile de faire confiance à quoi que ce soit avec un numéro de version commençant par 0, par exemple.
Deuxièmement, certains problèmes se prêtent mieux à certains environnements ; ou les approches de programmation cas particulier, le langage F # fréquemment « est plus logique » à celles avec un arrière-plan mathématique et permet parfois d'écrire certains types de code. Tel était le cas de quelques années lorsque j'ai écrit la bibliothèque Feliza (dans le cadre de la série montrant comment utiliser SMS dans le nuage en utilisant le nuage Tropo) ; Bien que cela pourrait avoir été écrite en c#, F # de correspondance et modèles « actifs » rendaient beaucoup plus facile à écrire qu'avais le fait cela en c#. Cela vaut pour JavaScript (voire plus).
Dernier et peut-être plus important est que parfois l'environnement dans lequel le code s'exécute simplement naturellement favorise une plateforme sur un autre. Par exemple, les nombreuses organisations qui hébergent des applications dans Azure utilisent Active Directory comme leur authentification et l'autorisation de base ; Par conséquent, ils souhaitent amèneront continuer à utiliser Active Directory pour les nouvelles applications écrites, .NET ou Node.js. Accès à Active Directory est généralement beaucoup plus simple et plus facile à partir d'un environnement .NET que rien d'autre, donc la bibliothèque Edge.js offre une pratique « trappe, » pour ainsi dire, pour faciliter l'accès à Active Directory.
Synthèse
Il a été un peu plus clair cette fois-ci, essentiellement parce que la bibliothèque Edge.js élimine la majeure partie du travail hors de l'utilisation de plus de l'environnement .NET. Et il ouvre un grand nombre de nouvelles options pour Azure remarquables, car vous pouvez désormais accéder à pas un seul mais deux écosystèmes riches et complètes d'outils, des bibliothèques et des packages.
Notez qu'il existe une colonne entière en attente d'être écrites va la direction, à la façon : Dans de nombreux cas, certains types d'applications sont plus faciles à écrire à l'aide de divers packages disponibles dans le référentiel npm, que Edge.js maintenant s'ouvre pour le développeur .NET traditionnel. Et avec la dernière version d'ouvrir la source de Chakra, le cœur de Microsoft JavaScript qui permettre « brancher » pour l'environnement de nœud comme un plug-in dans le désordre, s'affiche, davantage de possibilités d'utiliser JavaScript dans le cadre d'une application .NET « standard », y compris même la possibilité d'héberger un interpréteur JavaScript au centre de votre application. Cela a son propre implications intéressantes lorsque vous arrêtez le penser.
Il existe quelques points que je souhaite aborder avant de quitter le serveur complètement, mais je suis d'espace, donc pour le moment... bon codage !
Ted Newardest mentor, conférencier et consultant de polytechnology basée à Seattle. Il a écrit plus de 100 articles, est un MVP F #, l'intervenant de l'INETA et a créé et coécrit une dizaine d'ouvrages. Vous pouvez le contacter à l'adresse ted@tedneward.com si vous souhaitez qu'il vienne travailler avec votre équipe, ou vous pouvez lire son blog à l'adresse blogs.tedneward.com.
Merci aux experts techniques suivants d'avoir relu cet article : Shawn Wildermuth