J'ai décidé de m'habituer à utiliser Javascript comme mon serveur (j'utilise Node.js) pour configurer un serveur web, créer des serveurs de serveur et beaucoup plus. C'est un projet plutôt important, ce qui signifie que je dois m'habituer à la langue et obtenir moi-même une configuration optimale avant de réellement commencer à éviter les tracas inutiles et inutiles.Comment passer du langage basé sur les objets au serveur Node.js Javascript pour les grands projets?
Je cherchais des sources qui expliqueraient les bases de la programmation fonctionnelle dans les grands projets. Malheureusement, la plupart des sources ne parlent que de Javascript de base pour des astuces simples dans un navigateur.
Deux liens utiles expliquant comment la création d'objets fonctionne en Javascript étaient http://howtonode.org/object-graphs et http://howtonode.org/object-graphs-2.
En fin de compte, il semble plus judicieux de créer un objet comme:
function MyObject(constructorMemberOne, constructorMemberTwo) {
this.constructorMemberOne = constructorMemberOne;
this.constructorMemberTwo = constructorMembertwo;
this.doSomething = function doSomething() {
//
}
}
Maintenant, je suis à la recherche d'une référence linguistique complète Javascript. Jusqu'à présent, https://developer.mozilla.org/en/JavaScript/Reference semble être le plus complet.
Q1: est-ce la référence de langage ECMAScript recommandée? Je demande surtout parce que c'est une entreprise qui travaille principalement dans l'industrie du navigateur, mais Javascript n'est pas seulement là pour les navigateurs - peut-être y a-t-il des sources que je ne connais pas.
Deuxièmement, je suis habitué à créer un nouveau fichier pour chaque classe que je crée où le nom du fichier représente le nom de la classe. Q2: Est-ce une pratique recommandée en Javascript (V8, Node.js) aussi? Comment "importer" cette classe? Cette «importation» m'amène à ma confusion au sujet de «require» de Node.js. Je sais que ce n'est pas pareil. Exiger fondamentalement charge un autre fichier qui a alors son propre espace de noms, ce qui signifie que ses variables sont hors de la portée du fichier qui nécessite ce fichier. Pour mes classes cependant, je veux avoir des méthodes qui sont disponibles pour la classe qui "importe" (des citations comme je ne suis pas sûr que ce soit même possible) cette classe. Par exemple .:
var utils = require("utils/MainUtils.js");
utils.doSomething();
Pour autant que je sache, cette méthode doSomething() est disponible uniquement si elle a été définie comme:
function MainUtils() {
exports.doSomething = function doSomething() {
//
}
}
Q3: Est-ce exact? Cela ne semble-t-il pas tout à fait anormal?
Q4: Y at-il d'autres blogs ou ressources qui sont utiles pour faire fonctionner mon installation, comme howtonode.org? Enfin, Q5: Y a-t-il eu des efforts pour rendre tout cet héritage, création d'objet, structure de projet, espace de nommage etc. plus facile pour les grands projets? Des bibliothèques ou quelque chose dans ce but?
J'espère que mes questions sont claires. Toute aide est appréciée. Merci.
Merci, je ne suis pas sûr des fichiers cependant. Je pense qu'avoir un fichier pour chaque classe rend la structure beaucoup plus facile à comprendre. Vous avez dit que je devrais le garder en morceaux gérables, mais qu'est-ce qui définit un morceau gérable? Une classe par fichier semble une bonne définition qui ne cause pas beaucoup de confusion, mais ce n'est pas recommandé? Est-il même possible du tout? Je suppose que l'on devrait require() chaque classe si elle est séparée par fichier? Aussi, connaissez-vous plus de sources que je peux regarder (Q4, Q5)? – Tom
Aussi, que pensez-vous de http://www.prototypejs.org/learn/class-inheritance? Y a-t-il plus de tels cadres? Est-ce que l'un d'entre eux est largement utilisé? – Tom
"Ancienne syntaxe" de Prototype que je ne considérerais pas en raison de la méchanceté d'utiliser une instance de 'new Person' comme prototype. La "nouvelle syntaxe" est correcte, je suppose, mais cela cache en quelque sorte ce que JS fait vraiment avec les prototypes, et l'implémentation est plutôt lourde, ajoutant une méthode wrapper supplémentaire pour chaque méthode de classe ayant le premier argument '$ super' (oui, il doit s'agir de ce nom exact, et il fait cette vérification en utilisant la décomposition des fonctions ... eek, c'est un vilain bidouillage). – bobince