ASP.Net MVC avec le service Web comme modèle?

Question

Est-ce que quelqu'un a des conseils ou des astuces sur l'utilisation d'un service Web comme modèle dans une application ASP.Net MVC? Je n'ai vu personne écrire à propos de ça. Je voudrais créer une application MVC, mais ne pas lier à l'aide d'une base de données spécifique, ni limiter la base de données à l'application MVC unique. Je pense qu'un service web (RESTful, probablement ADO.Net Data Services) est la voie à suivre.

Answer 1

Modifier 2010-11-27; clarifié mes pensées, ce qui était vraiment nécessaire. Un service Web expose la fonctionnalité à travers différents types d'applications, et non pour l'abstraction dans une seule application, le plus souvent. Vous pensez probablement plus à un moyen d'encapsuler des commandes et des lectures d'une manière qui n'interfère pas avec la programmation de votre contrôleur/vue.

Utilisez un service depuis un bus de service si vous souhaitez effectuer un découplage et effectuez un modèle asynchrone dans vos pages asynchrones. Vous pouvez voir Rhino.ServiceBus, nServiceBus et MassTransit pour les implémentations natives .Net et RabbitMQ pour quelque chose de différent http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/.

Editer: J'ai eu le temps d'essayer Rabbit d'une manière qui a poussé les messages à mon service qui à son tour poussé les mises à jour de l'application de tenue de livres. RabbitMQ est un courtier de messages, alias MOM (middleware orienté message) et vous pouvez l'utiliser pour envoyer des messages à votre serveur d'applications.

Vous pouvez également simplement fournir des interfaces de service. Lisez le document Domain Driven Design d'Eric Evan pour une description plus détaillée.

Les interfaces de service REST-deal traitent beaucoup de données, et plus particulièrement de ressources adressables. Il peut grandement simplifier votre modèle de programmation et permet un excellent contrôle de la sortie via le protocole HTTP. Le prochain modèle de programmation de WCF utilise le vrai repos tel que défini dans la thèse originale, où chaque document devrait dans une certaine mesure fournir des URI pour la poursuite de la navigation. Avoir un look at this. (Dans ma première version de ce post, je regrettais REST pour être «lent», peu importe ce que cela signifie) API basées sur REST sont également à peu près ce que CouchDB et Riak utilise. ADO.Net est plutôt crap (!) [N + 1 problèmes avec la collecte paresseuse en raison de code à l'implémentation, fuite d'accès aux données - vous avez toujours besoin de votre contexte db où votre code de requête est etc] par rapport à par exemple LightSpeed ​​(commercial) ou NHibernate. Spring.Net vous permet également d'intégrer des interfaces de service dans leur contenu avec une façade de service Web, mais (sans l'avoir parcouru depuis un moment) je pense que c'est un peu trop dans sa configuration.

Édition 1: Avec ADO.Net j'entends ici la "meilleure pratique" par défaut avec DataSets, DataAdapter et l'itération de beaucoup de lignes d'un DataReader; il engendre un code plutôt laid et difficile à déboguer. Le N + 1, oui, c'est le cadre de l'entité.

(Edit 2: EntityFramework ne me impressionne pas non plus!)

Edit 1: Créez votre couche de domaine dans un ensemble séparé [alias. Core] et y fournir tous les services de domaine et d'application, puis importer cet assembly à partir de votre application MVC spécifique. Enroulez l'accès aux données dans un DAO/Repository, via une interface de votre assembly principal, que votre assembly de données référence et implémente ensuite. Câblez l'interface et l'implémentation avec IoC. Vous pouvez même programmer quelque chose pour la découverte de service dynamique avec les bus de service mentionnés ci-dessus, à résoudre pour les interfaces. WCF utilise des interfaces comme celle-ci et la plupart des bus de service ci-dessus; vous pouvez fournir un sous-composant dans votre conteneur IoC pour le faire automatiquement.

Édition 2: Un bon combo pour ce qui précède serait CQRS + EventSourcing + ReactiveExtensions. Votre modèle d'écriture prendrait des commandes, votre modèle de domaine déciderait de les accepter, il enverrait des événements dans le pipeline des extensions réactives, peut-être aussi sur RabbitMQ, que votre modèle de lecture consommerait.

Mise à jour 2010-01-02 (modifier 1)

La plaisanterie de mon idée a été codifiée par quelque chose appelé Deki rêve. Ils ont fait un screencast où ils traitent presque toutes les parties d'une application web comme un (web) -service, qui est également exposé avec REST.

Ils ont créé un cadre hautement parallèle en utilisant des co-routines pour gérer cela, y compris leur propre piscine de thread élastique.

Pour tous les non-diseurs dans cette question, dans votre visage: p! Listen to this screen-cast, en particulier à 12 minutes.

The actual framework is here.

Si vous êtes dans ce genre de programmation, un coup d'oeil à how monads work et their implementations in C#. Vous pouvez également lire sur CoRoutines.

Bonne année!

Update 2010-11-27 (modifier 2)

Il est avéré Coroutines obtenu productized la tâche bibliothèque parallèle de Microsoft. Votre tâche implémentent maintenant les mêmes fonctionnalités, car elle implémente IAsyncResult. Caliburn est un cadre cool qui les utilise.

Les extensions réactives portaient les compréhensions de monad au niveau d'asynchronité suivant.

Le monde ALT.Net semble aller dans la direction dont j'ai parlé lorsque j'ai écrit cette réponse la première fois, mais avec de nouveaux types d'architectures que je connaissais peu.

Answer 2

Vous devez définir vos modèles de manière agnostique pour l'accès aux données, par ex. en utilisant le modèle Repository. Vous pouvez ensuite créer des implémentations concrètes soutenues par des technologies spécifiques d'accès aux données (Web Service, SQL, etc.).

Answer 3

Quelle est la probabilité, ou la pertinence, de découpler votre application MVC de votre base de données? Combien de fois avez-vous vu, dans la vie de votre application, un changement de SQL Server à Oracle? Depuis les 10 dernières années de projets que j'ai livrés, ce n'est jamais arrivé. Les architectures sont comme les oignons, elles ont des couches d'abstractions au-dessus des choses dont elles dépendent. Et si vous utilisez un SGBDR pour le stockage, c'est au cœur de votre architecture. Se faire abstraction de la base de données pour pouvoir l'échanger est une erreur.

Désormais, vous pouvez découpler l'accès à votre base de données de votre domaine et le modèle de référentiel est l'une des manières de le faire. La plupart des solutions matures utilisent un ORM ces jours-ci. Vous pouvez donc consulter NHibernate si vous voulez une technologie mature ou ActiveRecord/linq2sql pour un modèle d'enregistrement actif plus simple sur vos données.

Maintenant que vous avez votre stratégie de données en place, vous avez un domaine de quelque sorte.Lorsque vous exposez des données à votre client, vous pouvez choisir de le faire via un modèle MVC, où vous enverrez généralement des DTO générés à partir de votre domaine pour le rendu, ou vous pouvez décider de tirer parti d'un style d'architecture tel que REST. , en fournissant des liens et des représentations personnalisées.

Vous passez d'un accouplement serré à un accouplement plus lâche en allant vers les couches externes de votre solution.

Si votre question était cependant de construire une application MVC au-dessus d'une architecture REST ou de services web, et de l'utiliser comme modèle ... Pourquoi s'embêter? Si vous voulez avoir un modèle de domaine, pourquoi ne pas le réutiliser dans votre système et vos services là où c'est logique?

Générer une interface utilisateur à partir d'une application MVC et générer des documents nécessaires pour une architecture RESTful sont deux contextes complètement différents, se fondant l'un sur l'autre va juste causer beaucoup plus de douleur que nécessaire. Et vous sacrifiez la performance.

Selon votre scénario exact, mais le service XML distant comme modèle dans MVC, par expérience, ce n'est pas une bonne idée, c'est probablement sur-ingénierie et sans tenir compte du besoin d'un domaine pour commencer.

Answer 4

Cela dépend vraiment de la taille de ce projet mvc. Je dirais garder l'interface utilisateur et le domaine dans le même environnement de fonctionnement si le site Web va être utilisé par un petit nombre d'utilisateurs (< 5000). D'un autre côté, si vous envisagez d'accéder à un site auquel des millions de personnes auront accès, vous devez penser à la distribution, ce qui signifie que vous devez créer votre site de manière à pouvoir le faire évoluer. Cela signifie que vous devrez peut-être utiliser des serveurs supplémentaires (Web, application et base de données). Pour que cela fonctionne bien, vous devez découpler votre site d'interface utilisateur mvc de l'application. La couche d'application contient généralement votre modèle de domaine et peut être exposée via WCF ou un bus de service. Je préférerais un bus de service car il est plus fiable et pourrait utiliser des files d'attente persistantes comme msmq.

J'espère que cela aide