MVC avec services Web

Question

Je travaille sur la construction d'une application basée sur SOA. J'ai beaucoup de services métier que je devrais les rendre disponibles en tant que composants à d'autres applications (donc j'utiliserai des services Web -SOAP-).

L'application couche de présentation est MVC.

1- Modèle: Contient des méthodes DataBase (ORM est utilisé).

2- Contrôleur: Contient des appels aux méthodes du modèle ainsi que des méthodes pour gérer les actions d'affichage simples.

3- Affichage: Contient uniquement du contenu de rendu. Alors, pouvez-vous me donner un scénario simple, comment puis-je combiner le service web avec mon application MVC, ma suggestion est de séparer le modèle en services web, n'est-ce pas?

Answer 1

je aimerais aborder la façon suivante: (YMMV)

• Construire un boîtier de montage de niveau de toutes les données de votre accès aux données. Appelez le DAL. Il contiendra toutes les méthodes d'accès aux données. Cela permettra la réutilisation, mais permettra également les méthodes utilisées par une application ci-dessous. C'est là que votre modèle EF peut vivre.

• Construire 2 projets Web: MVC et services Web. Chacun mettra en œuvre la logique métier pour satisfaire leurs exigences respectives. Ils référencent et appellent dans la couche d'accès numérique au besoin pour l'accès aux données. Comme vous l'avez noté, ce sont deux services de niveau présentation. L'un dispose d'une interface utilisateur, l'autre est un point de terminaison de communication pour les consommateurs de services Web distants.

• Déployez les deux sur un serveur d'applications si nécessaire. Suggérez de créer 2 applications/sites dans IIS (c'est-à-dire "Web" et "WebServices"). Cette séparation des applications garantit que l'on peut être changé/downtimed/versionné sans affecter l'autre.

• Le projet/l'application MVC aura toujours ses modèles, vues et contrôleurs comme d'habitude. Le plus grand changement ici est que les modèles ne seront utilisés que pour ViewModels si nécessaire. Il contiendrait toute logique métier pour satisfaire les exigences de l'interface utilisateur. Ses méthodes de contrôleur appelaient les méthodes publiques DAL appropriées selon les besoins.

• Le projet/l'application de services Web pourrait être modifié indépendamment selon les besoins, tandis que l'accès aux données resterait.

Answer 2

1) Placez toutes vos opérations de service derrière une interface.

2) Envisagez d'utiliser un conteneur Inversion of Control pour utiliser l'injection de dépendances dans votre application. Cela vous permet de simuler vos dépendances et de tester plus facilement la logique de votre contrôleur. Certains exemples sont Windsor, Ninject, StructureMap.

3) Envisagez d'utiliser des modèles de vue fortement typés pour vos vues, au lieu des objets avec lesquels votre ORM travaille. Vous aurez besoin de mettre en place des classes de cartographie pour aider à gérer cela, mais beaucoup de la douleur peut être enlevée en utilisant quelque chose comme AutoMapper.

Voici quelques liens bons sur le sujet:

• How we do MVC – View models
• ASP.NET MVC View Model Patterns

Answer 3

Ne jamais utiliser les services Web pour l'intérêt de l'utilisation des services Web: Vous devez d'abord avoir un problème qui doit être résolu et voyez que les services Web sont la meilleure solution à votre problème. Ainsi, en fonction de vos besoins, les services Web peuvent être utilisés de différentes manières. Par exemple, puisque vous dites que MVC est votre couche de présentation , vous pouvez insérer des services Web en tant que couche entre le Modèle et le Contrôleur. Plutôt que d'invoquer directement votre modèle (couche de données), le contrôleur appelle vos services Web et fournit une interface Web aux services qui seraient autrement disponibles via votre API SOAP.

Une autre option consiste à faire en sorte que votre frontal MVC et les services SOAP accèdent à une couche logique métier/données commune, chacun fournissant sa propre "API" pour le même serveur principal.

Mais encore une fois, je souligne: les services Web ne doivent pas être utilisés comme solution à la recherche d'un problème. Si ce n'est pas évident pour vous où les services Web devraient s'intégrer dans votre architecture, vous êtes très probablement mieux sans eux.