Je fais pas mal de travaux ASP.NET (C #, MVC), mais la plupart sont du développement web typique. Je fais de l'architecture Restful en utilisant des dépôts CRUD. La plupart de mes clients n'ont pas beaucoup d'exigences avancées dans leurs applications.

Je regarde maintenant node.js et ses implications en termes de performances (je suis accro à la vitesse), mais je ne me suis pas beaucoup plongé dans tout cela.

Je me demande si

• node.js peut remplacer de manière réaliste mon développement Web typique en C # et ASP.NET MVC (pas en réécrivant les applications existantes, mais en travaillant sur de nouvelles)
• node.js peut compléter une application ASP.NET MVC en ajoutant une certaine qualité asynchrone à l'architecture existante.

Existe-t-il des cas d'utilisation pour / contre C # et node.js?

Éditer

J'adore ASP.NET MVC et je suis super excité de savoir où ça va. J'essaie juste de voir s'il existe des cas d'utilisation spéciaux qui favoriseraient node.js

Je regarde maintenant node.js et ses implications en termes de performances (je suis accro à la vitesse), mais je ne me suis pas beaucoup plongé dans tout cela.

Profil, profil, profil. C'est la seule façon de savoir que vos accélérations ont le bon effet. Vous pouvez deviner que c'est assez rapide. Mais la plupart des gens aiment optimiser prématurément. C'est pire que de jouer avec vous-même lors d'un rendez-vous.

Je me demande si node.js peut remplacer complètement mon développement web typique en C # et ASP.NET MVC, s'il est meilleur en complément de C # et ASP.NET MVC, ou s'il y a des choses qui devraient juste "laisser suffisamment bien tranquille" ".

Existe-t-il des cas d'utilisation pour / contre C # et node.js?

Bien sûr, si vous êtes dans une boutique qui écrit régulièrement du code en C #, vous devez utiliser MVC (c'est beaucoup mieux que WebForms et il s'appelle WebPages). Vous ne perdrez pas beaucoup de temps à la formation d'outillage, et c'est quelque chose que vos flux de travail devraient déjà gérer.

Ce que vous ne semblez pas indiquer ci-dessus, ce sont les raisons de choisir chacun. Vous avez donné deux options de marché actuelles, l'une encore en phase Alpha, l'autre sur sa troisième année complète de sortie de plate-forme. Je ne voudrais pas comparer les modèles actuels de voitures électriques avec les hybrides Honda qui sont déjà sur le marché. Ils sont dans deux ligues différentes.

Maintenant, voici une raison pour que vous restiez loin de node.js, si vous êtes nominalement une boutique C #.

Vous ne travaillez pas actuellement dans les E / S à événements asynchrones, vous travaillez actuellement dans un format procédural.

C'est l'antithèse de ce que nodejs va faire pour vous.

Cependant, si vous écrivez fréquemment du code asynchrone en C # et que vous l'utilisez beaucoup dans un style événementiel, alors oui, node.js est à prendre en compte.

Voici ce que vous abandonnerez:

• IIS - Ceci est en fait important pour beaucoup de gens. Des choses comme l'intégration native A / D sont déjà terminées et assez exemptes de bogues. En fait, node.js s'intègre désormais bien avec IIS.
• Modèles de rasoir - Si vous avez fait un MVC C # sérieux, alors vous utilisez et aimez Razor et à quelle vitesse vous pouvez produire des choses. Il existe des modèles similaires dans le nœud, et je ne suis certainement pas en train de frapper le nœud, mais l'ensemble de la chaîne d'outils est déjà présent en C #, et une grande partie est actuellement en cours de construction dans le monde des nœuds. NB: une grande partie de cet outillage est maintenant plutôt mature _
• compilation des dll au moment de la compilation - node.js est généralement compilé à la volée, c'est-à-dire que tous les chemins ne sont pas vérifiés au démarrage. Il est tout à fait possible d'avoir un code vraiment mauvais dans le nœud que personne ne touche, vérifie ou teste.
• Tous les outils actuellement intégrés dans VS que vous utilisez quotidiennement - Il n'y a tout simplement pas beaucoup de support VS pour javascript. En partie parce que tout en javascript est tellement dynamique. NB: Microsoft travaille évidemment sur le support d'outillage pour javascript _

Voici ce que vous gagnerez:

• tout ce que vous développez sera dans le même langage, en supposant que vous effectuez des scripts côté client ainsi que côté serveur. (ou pourquoi envisageriez-vous même le javascript sur le serveur)

Donc, comme je semble dénigrer entièrement Node ici, permettez-moi de souligner que le nœud est ma langue de jeu à la maison, je l'adore et j'aide les gens à le déboguer parfois sur les serveurs de discussion stackoverflow (salle 642). Je vois qu'il a un grand et formidable potentiel à l'avenir.

Je dis juste, ne jetez pas le bébé et demandez-vous pourquoi l'eau du bain est sale.

Vous n'avez pas donné de raison pour laquelle vous devriez renoncer à vos années d'expérience et commencer quelque chose de nouveau. Les mauvais outils sont-ils? Pas du tout. Les deux sont excellents et font du développement un jeu d'enfant.

Le nœud peut-il remplacer C #? Oui, bien sûr. Tout comme PHP, Java ou Ruby. Vous ne posez pas de questions à ce sujet.

Voici comment vous savez quand vous êtes prêt à programmer node.js au lieu de C #:

• Vous envisagez d'écrire un livre pour aider d'autres personnes à "obtenir du javascript" au lieu des anciens programmes ennuyeux qu'ils ont déjà écrits en C #, etc.
• Vous avez des problèmes avec les E / S synchrones (bloquantes) empêchant vos applications de faire un travail réel.
• Vous n'utilisez AUCUNE bibliothèque en C # autre que le MVC par défaut et cela uniquement pour le routage, et vous êtes presque sûr que vous pouvez faire un meilleur moteur de routage, et vous codez tout aussi près que possible du métal.
• Chaque objet de données que vous concevez, vous le voyez comme un hachage au lieu d'un objet fortement typé.

Si vous venez de faire une architecture reposante en utilisant des référentiels CRUD, il n'y a aucune bonne raison de porter une application existante sur node.js.

Si vous écrivez une nouvelle application qui fait REST et CRUD, il peut y avoir de bonnes raisons d'utiliser node.js dès le début.

Cela dépend vraiment de l'application.

Par exemple, personnellement, j'écrirais les applications REST / CRUD entièrement dans node.js car c'est une préférence personnelle. Le nœud est génial à développer, ASP.NET MVC était un cadre restrictif ennuyeux pour moi.

Verdict: les deux outils font le travail. S'il n'y a pas d'exigences spécifiques qui favorisent .NET ou le nœud, utilisez ce que vous voulez. c'est à dire c'est la préférence personnelle.

Cependant, je peux énumérer certains des avantages évidents des deux plates-formes

ASP.NET

• Intégration Windows / .NET. Si vous voulez que votre pile Microsoft soit étroitement couplée et hautement intégrée, vous voulez .NET
• main-d'œuvre facilement disponible
• Cadres monolothiques qui tiennent votre main
• A un ensemble de fonctionnalités qui fonctionnent hors de la boîte. Si vous êtes satisfait de ces fonctionnalités, cela améliore la productivité. Si vous souhaitez des fonctionnalités personnalisées, vous finissez par vous battre contre l'outil et réduisez la productivité.

Node.js

• Langue unique pour l'ensemble de votre pile Web (si vous utilisez des bases de données noSQL qui utilisent js pour leurs "requêtes" comme canapé / mongo).
• Idéal pour les applications Web douces en temps réel utilisant des outils tels que socket.io
• Idéal pour la mise en réseau de la colle lorsque tout ce que fait votre serveur est de parler à n points d'extrémité distants de différents types.
• Vous donne seulement les fonctionnalités minimales nues hors de la boîte. Cela signifie que vous pouvez créer votre application de la manière hautement personnalisée que vous souhaitez.
• Collection de petits outils de style Unix qui font une chose et une chose qui sont faciles à mélanger et à assortir
• npm : bonne gestion des packages
• riche communauté open source