Le but d'une couche de service et ASP.NET MVC 2

Question

Dans un effort pour comprendre MVC 2 et tenter d'obtenir mon entreprise à adopter comme une plate-forme viable pour le développement futur, je fais beaucoup de lecture ces derniers temps. Ayant travaillé avec ASP.NET assez exclusivement au cours des dernières années, j'ai eu un peu de rattrapage à faire.

À l'heure actuelle, je comprends le modèle référentiel, les modèles, les contrôleurs, les annotations de données, etc. Mais il y a une chose qui me empêche de comprendre complètement assez pour commencer à travailler sur une application de référence.

Le premier est le motif de couche de service. J'ai lu beaucoup de messages de blog et des questions ici sur Stack Overflow, mais je ne comprends toujours pas tout à fait l'objet de ce modèle. Je regardais la série vidéo entière à MVCCentral sur l'application Tracker Golf et aussi regardé le code de démonstration, il a écrit et il me semble que la couche de service est juste un autre emballage autour du modèle référentiel qui ne fonctionne pas de travail du tout.

Je lis aussi ce message: http: //www.asp. net / en savoir / mvc toutefois, si vous êtes / tutoriel-38-cs.aspx et il semblait répondre un peu ma question, à l'aide d'annotations de données pour effectuer votre validation, cela semble inutile.

J'ai cherché des démonstrations, des postes, etc., mais je ne peux pas sembler trouver tout ce qui explique simplement le modèle et me donne des preuves convaincantes de l'utiliser.

Quelqu'un peut-il s'il vous plaît me donner une 2e année (ok, peut-être de qualité 5) raison d'utiliser ce modèle, ce que je perdrais si je ne le fais pas, et ce que je gagner si je le fais?

Answer 1

Dans un modèle MVC, vous avez des responsabilités séparées entre les 3 joueurs:. Modèle, Vue et Contrôleur

Le modèle est responsable de faire les choses d'affaires, la vue présente les résultats de l'entreprise (fournissant également une contribution à l'entreprise de l'utilisateur), tandis que le contrôleur agit comme la colle entre le modèle et la vue, séparant le fonctionnement interne de chacun de l'autre.

Le modèle est généralement soutenu par une base de données afin que vous avez des accès OTI qui. Votre entreprise fait un peu ... eh bien ... entreprises et magasins ou extrait les données dans / de la base de données.

Mais qui coordonne les OTI? Le controlle? Non! Le modèle devrait.

Entrer la couche de service. La couche de service assurera un haut degré au contrôleur et gérer d'autres joueurs (OTI, d'autres services, etc.) (niveau inférieur) dans les coulisses. Il contient la logique métier de votre application.

Qu'est-ce qui se passe si vous ne l'utilisez pas?

Vous devez mettre le quelque part logique métier et la victime est généralement le contrôleur.

Si le contrôleur est centrée sur le web, il devra recevoir son entrée et fournir une réponse que les demandes HTTP, les réponses. Mais si je veux appeler mon application (et avoir accès à l'entreprise, il fournit) à partir d'une application Windows qui communique avec RPC ou autre chose? Qu'est-ce donc?

Eh bien, vous devrez réécrire le contrôleur et faire l'agnostique client logique. Mais avec la couche de service que vous avez déjà. Yyou ne ont pas besoin de réécrire les choses.

La couche de service assure la communication avec DTO qui ne sont pas liés à une mise en œuvre du contrôleur spécifique. Si le contrôleur (peu importe quel type de contrôleur) fournit les données appropriées (pas de mater la source) de votre couche de service fera sa chose fournir un service à l'appelant et de cacher l'appelant de toutes les responsabilités de la logique métier impliqués.

Answer 2

Je dois dire que je suis d'accord avec DPB avec ce qui précède, l'emballage est-à-dire la couche de service réutilisable, mockable, je suis en train d'inclure cette couche dans mon application ... voici quelques-unes des questions / exigences I je suis méditer sur (très vite: p) qui pourrait être de l'aide à youeself ...
1. portails multiples (par exemple portail bloggers, portail client, portail interne) qui seront nécessaires pour accéder par de nombreux utilisateurs différents. Ils doivent tous être des applications ASP.NET MVC séparées (une exigence importante)
2. Dans les applications elles-mêmes des appels à la base de données seront similaires, les méthodes et la façon dont les données sont traitées de la couche du référentiel. Sans doute certains contrôleurs de chaque module / portail fera exactement ou une version surchargée du même appel, d'où un besoin éventuel d'une couche de service (code aux interfaces) que je puis compiler dans un projet de classe distincte.
3. Si je crée un projet de classe distincte pour ma couche de service que je peux avoir besoin de faire la même chose pour la couche de données ou le combiner avec la couche de service et de garder le modèle loin du projet Web lui-même. Au moins de cette façon que mon projet se développe, je peux jeter la couche d'accès aux données (à savoir LinqToSql -> NHibernate), ou un membre de l'équipe peut sans travailler sur un code dans tout autre projet. L'inconvénient pourrait être qu'ils pourraient tout faire sauter lol ...