15

Microsoft fournit un modèle fantastique pour développer Angular (pas AngularJS) dans ASP.NET Core comme indiqué dans leur article "Building Single Page Applications on ASP.NET Core with JavaScriptServices".Modèle ASP.NET Core Angular: app.module.client vs app.module.server

Bien qu'il soit très simple, il y a une partie du modèle qui m'a pris au dépourvu: au lieu d'avoir simplement un fichier app.module.ts, il y a à la fois un app.module.client.ts et un app.module.server.ts.

screenshot of <code>app.module.client.ts</code> and <code>app.module.server.ts</code>

je ne ai pas trouver quelque chose qui explique cela sur le web. Quelqu'un a-t-il une idée de la raison pour laquelle il existe ces deux fichiers distincts pour le module d'application, quelles sont leurs utilisations spécifiques, comment les utiliser, etc.?

Si elle aide à tous, voici ce que le gabarit ressemble:

full ASP.NET Core Angular template

Je dois souligner que ClientApp/app/models et ClientApp/app/services sont deux dossiers que j'ai ajouté à mes propres fins; ils ne font pas partie du modèle. En outre, app.module.shared.ts est en fait très simple et empêche juste d'avoir à écrire du code deux fois, donc ne vous inquiétez pas à ce sujet.

Voici ce que les deux fichiers ressemblent:

<code>app.module.client.ts</code> and <code>app.module.server.ts</code> code side-by-side

Répondre

4

Permettez-moi de commencer par préfacer que je ne suis pas à 100% sur l'exactitude de cette déclaration, mais puisque personne ne semble avoir d'autre réponse, Je vais essayer.

Microsoft SPA avec Angular 2 a utilisé Angular Universal pour effectuer le rendu AOT. Il a maintenant été amélioré pour utiliser Angular 4, qui n'utilise pas Angular Universal. Ma pensée est qu'il a plutôt divisé le app.module.ts dans un fichier client et serveur pour aider avec le rendu AOT.

Le fichier app.module.shared.ts est en fait simplement une constante globale utilisée par app.module.client.ts et app.module.server.ts. Parce que tout est rendu dans un couple de fichiers js lors de la publication, il n'est pas vraiment important qu'ils se séparent du fichier app.module.

+2

Ah, d'accord. Qu'en est-il de l'utilisation? Lorsque vous déclarez un composant par exemple, doit-il aller dans le client, le serveur ou partagé? Qu'en est-il des fournisseurs? Importations? Est-ce qu'une bonne règle empirique serait de simplement tout mettre en commun? Y a-t-il un cas dans lequel on devrait mettre spécifiquement quelque chose dans un dossier et pas dans l'autre? – NetherGranite

+1

J'ai trouvé que si j'essaie d'ajouter une référence à un service devant être utilisé par les composants, il faut ajouter de telles références dans les fournisseurs à la fois sur app.module.server et sur app.module.client. J'essayais de suivre https://channel9.msdn.com/Events/Visual-Studio/Visual-Studio-2017-Launch/WEB-103 (voir mon commentaire en bas) et j'ai dû ajouter des références aux exemples de services dans fichiers susmentionnés. – danfer

+1

Ce que j'ai fini par faire est de mettre à app.module.shared.ts l'importation de services et les ajouter dans le fournisseur partagé, que, à app.module.server et app.module.client juste ajouter des références à sharedConfig.providers à section fournisseurs du @NgModule de chacun des fichiers serveur et client. De cette façon, si besoin d'ajouter un nouveau service n'a pas à faire à chacun des fichiers, juste en partage. Testé avec 2 services différents et a bien fonctionné – danfer