Lorsque je suis allé à l'université, les enseignants disaient que, dans une bonne application structurée, vous avez une couche de présentation, une couche d'entreprise et une couche de données. C'est ce que j'ai entendu depuis plus de 5 ans.
Quand j'ai commencé à travailler, j'ai découvert que cela est vrai, mais il est parfois préférable d'avoir plus de trois couches. Il y a deux ou trois jours, j'ai découvert Cet article par John Papa qui explique comment utiliser le cadre d'entité dans l'application superposée. Selon cet article, vous devriez avoir:
La couche de service est, pour moi, l'une des meilleures idées que j'ai jamais entendues depuis que je travaille. Votre interface utilisateur est alors complètement "déconnectée" de la couche d'entreprise et des données. Maintenant, lorsque je suis allé plus profondément en examinant le code source fourni, j'ai commencé à avoir des questions. Pouvez-vous m'aider à me répondre?
question # 0 : Est-ce un bon modèle d'application Enterpise à votre avis?
hâte d'avoir de vos nouvelles. Passez un bon week-end!
marco
4 Réponses :
question n ° 0: est-ce une bonne perspective Modèle de candidature à votre avis?
Oui, pour la plupart des applications de ligne d'affaires au milieu de la route, c'est probablement un bon point de départ.
question n ° 1: où dois-je accueillir le Couche de service? Devrait-il être une fenêtre Service ou quoi d'autre?
Si vous êtes sérieux sur l'utilisation de services de WCF, je vous recommanderais de vous héberger automatiquement dans un service Windows. Pourquoi? Vous n'avez pas besoin d'avoir IIS sur le serveur, vous n'avez pas à vous fier à IIS pour héberger votre service, vous pouvez choisir votre adresse de service à votre guise et vous avez un contrôle complet sur vos options.
question n ° 2: dans le code source à condition que la couche de service expose juste un point final avec wshttpbinding. Cette est la liaison la plus interopérable mais (Je pense) le pire en termes de performances (en raison de la sérialisation et désérialisations d'objets). Est-ce que tu d'accord?
Non, le plus interopérable serait un
BasichttpLinding sans sécurité. Toute pile de savon sera capable de se connecter à cela. Ou ensuite unWebhttpbinding pour un service reposant - pour cela, vous n'avez même pas besoin de savon - juste une pile HTTP fera.Que utilisons-nous ??
interne, si les scénarios intranet sont en jeu (serveur et clients derrière le pare-feu d'entreprise): Toujours NetTCP - C'est le meilleur, le plus rapide, la plus polyvalente. Ne fonctionne pas bien sur Internet cependant :-( (besoin d'ouvrir des ports sur des pare-feu - toujours un problème)
externe:
Webhttpbinding ouBasichttpLinding , principalement en raison de leur facilité d'intégration avec des plates-formes non -.net
Ok donc dans un scénario où je dois ouvrir ma couche d'entreprise à une application interne, vous suggérez NetTCP, mais si cela doit être accédé par une application externe, vous suggérez WebhttpBinding ou WebhttpLinding. Parfait. Merci beaucoup.
Oui, utilisez définitivement le NETCP pour les applications internes et l'accès - votre meilleur choix. Extérieurement, il n'est généralement pas possible (en raison du fait que vous devriez piquer des trous dans des pare-feu pour le trafic de passer à travers - surtout presque impossible à faire ...)
Voici mes 5 cents:
0: oui
1: Je commencerais en l'accueillant dans IIS parce que c'est très facile et vous obtient quelque part rapide.
2: Si vous avez besoin de sécurité, utilisez définitivement oui, allez avec WSHTTPTPLINDING (ou peut-être même wsfedérationhttpbinding si vous souhaitez plus de sécurité de FANCE). Il fonctionne assez vite dans la pratique, même si vous le dites, il y a des frais généraux et peut être assez difficile à appeler d'autres plates-formes (telles que Java).
3: N / A
Enfin, n'oubliez pas de définir des objets de contrat de données de vos services dans un assemblage distinct pouvant être référencé à partir du service DLL et le consommateur de votre couche d'interface utilisateur.
Vos professeurs ont-ils également dit pourquoi vous devriez créer une telle architecture ;-)? Ce que vous manque dans votre question, vos besoins sont vos besoins. Avant que l'un de nous puisse vous dire s'il s'agit d'une bonne architecture ou d'un bon modèle, nous devons connaître les exigences de la demande. Les exigences non fonctionnelles ou les conditions d'une application doivent conduire la conception d'une architecture.
J'aimerais savoir quelle est la plus importante exigence non fonctionnelle de votre application? (Maintenabilité, portabilité, fiabilité ou ...). Par exemple, jetez un coup d'œil à http://fr.wikipedia.org/wiki/iso/iec_9126 < / a> ou http://www.serc.nl/quint-book/ << / p>
Je pense que nous, les architectes devraient créer des architectures en fonction des exigences de l'entreprise. Cela signifie que nous, les architectes devraient rendre l'entreprise plus consciente de l'importance des exigences non fonctionnelles.
question n ° 0: est-ce un bon modèle d'application Enterpise à votre avis?
Vous utilisez le modèle d'architecture de calques, cela signifie que les couches pourraient évoluer plus facilement les unes des autres. L'une des structures d'architecture les plus utilisées, notez que ce modèle présente également des inconvénients (performances, traçabilité).
Question n ° 1: Où dois-je héberger la couche de service? Devrait-il être un service Windows ou quoi d'autre?
difficile à répondre. L'hébergement d'un service dans IIS présente deux avantages, les échelles informatiques plus faciles et la traçabilité est plus facile (WCF dans IIS possède des charges d'options de surveillance). L'hébergement d'un service dans un service Windows vous donne plus d'options de liaison (reliure de pipe nommée / liaison TCP).
Question n ° 2: Dans le code source fourni à condition que la couche de service expose juste un point final avec WSHTTPTPLINDING. C'est la liaison la plus interopérable mais (je pense) le pire en termes de performances (en raison de la sérialisation et des désérialisations d'objets). Êtes-vous d'accord?
performance sage Les coûts de WSHTTPTPTPLING plus, mais cela marque haute sur l'interopérabilité. Donc, le choix dépend de vos besoins non fonctionnels.
Question n ° 3: Si vous êtes d'accord avec moi à la question 2, quel type de liaison utiliseriez-vous?
Les tuyaux nommés et la liaison TCP sont très rapides. La liaison de tuyaux de nom ne doit être utilisée que lors de la communication dans une seule machine. La liaison TCP pourrait être une option, mais vous devez ouvrir un port spécial dans le pare-feu.
Je sais que cette question est ancienne, mais je l'ai trouvée lors de la recherche de mon problème architectural actuel dans le refactoring une couche de service qui alimente une application Web. Alors que Googling, j'ai trouvé ces directives beaucoup plus modernes par Microsoft, en espérant que cela pourrait aider quelqu'un, voici les liens:
À propos de la couche d'entreprise et du modèle de domaine anémique découragé https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-pattatns/microservice-domain-model < / p>
sur la couche de persistance des données HTTPS: //docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-pattatns/infrastructructure-persistence-Layer-Design
Le carnet de motifs entier est téléchargeable en tant que PDF.
[modifier] Grâce à la documentation, j'ai trouvé une technique, que dans mon expérience a été utile d'éviter de nombreux étuis de commutation et d'appliquer des modèles puissants pour résoudre des problèmes complexes. La mise en œuvre suggérée est meilleure que la mienne (je devais utiliser des versions C # plus anciennes): https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-DDD-CQRS-Patterns/Enumeration-Classes-over -enum-types