-1
votes

Application de plusieurs solutions

Je prévois de créer un site Web à l'aide de ASP.NET CORE 2.0, Framework de l'entité, angulaire.

Je prévois de créer une solution avec différents projets (noyau, couche de données, interface utilisateur, etc.), mais le client cité "C'est une mauvaise idée, veuillez créer une solution séparée pour votre UI et votre API).

Comment puis-je créer plusieurs solutions et les laisser toujours interagir avec les autres? Quelle est la meilleure pratique? Si je crée une solution séparée pour mon interface utilisateur, comment puis-je communiquer avec le contexte EF qui est dans une solution différente?


3 commentaires

C'était un moment lol pour moi: P, de toute façon votre UI, qui est en angulaire, ne doit toutefois pas communiquer avec EF ... il communique avec l'API à l'aide de httpclient.


Je suppose que ce client ne veut pas tout dans le même projet comme Ce . Et voulez au moins 2 projet d'API et d'UI. Ne disant pas que c'est mauvais, le tutoriel est plus facile lorsque tout est dans le même projet.


Votre application angulaire communiquera avec votre API sur http. Donc, l'API et l'application angulaire peuvent être divisées en solutions séparées sans problème. Votre API appelle alors un cadre d'entité.


3 Réponses :


0
votes

La seule façon dont je peux imaginer que ce fonctionnement est de livrer chaque solution en tant qu'ensemble de microservices.

Cependant, votre architecture est maintenant différente. Une seule de ces solutions va être publiquement exposée. Les autres devront s'asseoir derrière un pare-feu pour s'assurer qu'ils ne peuvent pas être atteints par des utilisateurs externes. Mais tous auront des problèmes d'évolutivité et de sécurité.

Vous aurez donc un ensemble de services de données qui encapsulez le cadre d'entité et exposez les données via une API Web et une API logique commerciale accessible sur une API Web, puis votre UI (qui devrait inclure Angular).

API API API. Bienvenue sur des microservices.


1 commentaires

Il demande de fractionnement du frontend angulaire de l'API avec des solutions séparées. Je ne vois pas le problème architectural extrême ici ... juste diviser les solutions.



1
votes

solution est essentiellement juste un conteneur logique pour les projets, vous pouvez donc créer plusieurs solutions qui feront référence aux projets les mêmes (existants). Ceci est assez courant pour les grandes solutions comme par exemple xamarin.forms - vous pouvez avoir une grande solution avec tous les projets, puis avoir des solutions plus petites pour les développeurs qui doivent travailler avec seulement un sous-ensemble des projets.

Vous pouvez ajouter un projet existant à votre solution en cliquant avec le bouton droit de la souris sur la solution dans Solution Explorateur et choisissez Ajouter - Projet existant .


0 commentaires

1
votes

Je pense que votre client peut mal comprendre la solution. Regroupement de vos projets dans une solution n'affecte que votre espace de travail dans Visual Studio, cela ne signifie pas que vos projets ont des dépendances entre eux (à moins que vous ne le disiez explicitement dans leurs références)


2 commentaires

Cela pourrait très bien être le cas, à moins que le client ne soit un client de technologie qui achète le code après le fait et insiste sur des solutions séparées en tant que produit livrable. (J'ai vu des choses étranges.)


C'est encore plus étrange du fait qu'ils pouvaient facilement créer une autre solution et ajouter le projet UI à cette solution. Donc, à moins qu'ils veulent que leurs développeurs souffrent, je ne vois aucune raison de scinder des solutions.