Les arguments de l'utilisation de WCF / OData comme couche d'accès au lieu de EF / L2S / nHibernate directement

Question

Nous développons le trafic faible, mais la plupart des applications Web hautement spécialisées. Normalement, nous utilisons L2S, EF ou NHibernate comme couche d'accès et jette ensuite Asp.Net MVC et dans lequel les opérations de CRUD nous interrogeons le ISession / DataContext directement, mais pour des fonctions plus avancées / effets secondaires que nous l'avons mis dans une certaine forme de couche de service.

Maintenant, j'étais penser à la publication des données par le biais OData (WCF Data Service) et requête des contrôleurs (ou même de jQuery lorsque le moteur bon modèle apparaît) et de publier les opérations de services par le biais d'un service WCF (ou comme des méthodes personnalisées sur le service de données WCF?). Quels sont les avantages / inconvénients que cela pose-t architecture?

Est-ce que je gagne quelque chose, sauf une plus grande complexité et de la latence? De meilleures séparations des préoccupations (ou est-ce juste une illusion)?

Edit: Peut-il être une bonne idée de créer une solution ajax conduit avec par exemple. Services RIA WCF ? Ou faire une flexibilité lâche trop? Se sent comme vous pouvez complètement expédiez votre point de vue de votre logique puis, zut, on devrait être capable d'écrire juste pur HTML, même pas un asp.net MVC devrait être nécessaire? mais je pense qu'il ya beaucoup de nouveaux problèmes qui se posent?

Answer 1

Comme TomTom indique, vous ne voulez pas payer le coût de réalimentation pour OData lorsqu'il se trouve dans un processus. Si vous avez la ligne de visibilité directe à votre base de données et il est la base de données de votre propre application, alors il n'y a aucune raison de mettre WCF Data Services au milieu. Je continuerais d'utiliser l'une des autres options que vous avez mentionnés (L2S, EF, NHibernate).

Maintenant, si vous avez besoin d'exposer des données sur votre terminal http pour d'autres applications à consommer, ou même pour votre propre application si vous avez un code jQuery dans le client qui a besoin d'accéder aux données à partir du serveur, puis certainement un point final OData peut aider et WCF Data services est le moyen de créer un simple.

Answer 2

Ne pas le faire. Désolé, mais c'est une approche stupide sur-ingénierie. Vous êtes en un bloc et vous insistez sur l'exécution d'une connexion réseau et le codage de toutes les données passant dans XML et revenir en arrière, plus l'exécuter sur une connexion HTTP avec la sémantique de la requête limitée? Ne dites à personne que vous a même essayé.

La séparation de préoccupation est une illusion ici - vous remplacez un modèle de domaine hautement optimisé avec une couche de données simplifiée

.

Cela dit: J'adore OData - grande. Mais ce n'est pas dans la technologie du programme, il est une technologie AMONT, comme ASP.NET MVC - tout simplement pas pour l'utilisateur final, mais pour un autre programme pour intégrer dans vos données. Il doit être utilisé dans des scénarios similaires, et lors de l'exposition des données sur les frontières de la confiance. (Silverlight - par exemple - est une frontière de confiance que les demandes peuvent être truquées)

Il est pas optimisé pour remplacer dans le procédé applications haut de gamme couches à temps de fonctionner comme NHibernate.

Answer 3

TomTom a beaucoup de voix et bien qu'il n'a pas tort, il est aussi pas juste, malgré son ton persuasif.

Dans ce cas particulier, l'OP semble être écrire une application de style LOB intranet qui se probablement être entravée par un service OData mimant la base de données sous-jacente, mais s'il n'était pas mimer la base de données sous-jacente?

S'il construisait une application basée sur diverses sources de données futures ou inconnues, puis la couche de services peut unifier, présenter de nouveau, simplifier et regrouper ces services, même si une grande partie des requêtes éventuellement vers un serveur SQL dans la chambre d'à côté.

De même, si vous construisez une application d'échelle, et par échelle, je veux dire des millions d'utilisateurs attendent d'attendre quelques secondes entre les actions, pas des millions de FX transactions d'une heure, puis en plaçant une couche de services entre votre application la données est un modèle commun. L'évolutivité de l'Internet est basé sur de nombreux petits serveurs HTTP sans état et l'infrastructure de mise en cache entre les deux.

Dans la vraie vie, les mêmes requêtes sont exécutées nombre incalculable de fois, les gens rafraîchir les pages ou cliquez sur le même lien et encore. Personne ne demande vraiment 10m lignes, parce que pas beaucoup les humains peuvent regarder en une seule fois. Donc, travailler dans les petites pages conserve les données qui circulent et demande désentrelacement. Vous avez également la possibilité d'introduire une responsabilité partagée dans le cache de RAM dans la couche de services, ou même une base de données de RAM.

Vous pouvez même trouver que vous devez shard votre base de données ou le partitionner entre SQL et un magasin clé / valeur. Vous pouvez ensuite faire les jointures au niveau intermédiaire, mis à l'échelle sur et délester les choses se joindre et calculer à forte intensité de distance à partir du serveur de base de données.

La règle à l'échelle d'Internet est que la base de données est votre point chaud et que vous devez faire tout votre possible pour empêcher quiconque de lui parler! Soyez que cache HTTP local dans un iPad, dans votre FAI proxy, dans le cache de sortie IIS, ou dans un cache Redis, toutes ces couches contribuent à répartir la charge, alléger le fardeau.

Donc, si Carl est venu interviewer avec moi et m'a dit qu'il avait envisagé de mettre une couche de OData avant ses boîtes SQL, je serais intéressé d'entendre son raisonnement.

Answer 4

WCF Data Services et JSON de soutien OData, de sorte que vous pouvez réduire la charge utile en tirant parti de cela. De plus, avec WCF Data Services, vous pouvez contrôler complètement votre accès aux données. Vous ne devez pas rouler Entity Framework. Vous pouvez tout personnaliser. L'avantage est que la structure du protocole est entièrement gérée pour vous en utilisant WCF Data Services et OData. Et le service de la consommation MVC est un service de référence Ajouter loin. WCF Data Services fonctionne sur WCF si vous avez la possibilité de faire d'autres services Web au-delà de la livraison de type juste OData, il est donc extrêmement flexible.

Il y a des limites ici et là qui viennent avec la nature de OData, ainsi que la façon dont WCF Data Services gère OData, mais ils sont assez spécifiques et si elles apparaissent dans votre architecture il existe des moyens autour d'eux.

Si vous solution est isolé à une seule application Web, puis d'avoir la couche de données intégrées dans cette application fonctionne bien. Mais si vous avez besoin que ce soit d'avoir une autre application ou processus frappé la couche de données ou la logique métier partagé explorer ensuite la possibilité de mettre votre couche de données dans un service de données WCF est bien la peine. Par exemple, vous pouvez écrire un script PowerShell pour appeler une méthode de service Web en 2 lignes de code. Donc, si vous avez la logique de domaine que vous voulez être en mesure d'exécuter à partir de votre application Web et d'une ligne de commande ou tâche planifiée, votre couche de service de données WCF pourrait gérer ce scénario pour tous, sans avoir à dupliquer la logique ou le code.

De nombreuses façons de la peau d'un chat. Je l'ai utilisé les deux approches dans les applications commerciales et ne dirais pas que l'un ou l'autre doit être évitée. Ils ont tous deux fonctionnent bien et offrent beaucoup de valeur sans être préjudiciable.

Answer 5

Pour être juste, il y a des avantages à cette approche qui peut l'emporter sur les problèmes de performances, qui sont certes énormes. Une application construite de cette façon aura des ordres de grandeur plus la latence et peut coûter plusieurs fois plus en ressources informatiques pour exécuter d'une solution en cours.

Cela dit, dans les scénarios de développement où les ressources humaines sont limitées, cela peut fonctionner mieux. Il permet des entrepreneurs d'être rapidement engagé à écrire de nouveaux écrans ou de nouvelles applications entières très rapidement dans la langue qui leur convient. Les développeurs peuvent se lever à une vitesse plus rapide qu'une solution Homegrown propriétaire. Aucun mot de passe plus dans les fichiers de SA configuration, l'injection d'une couche de sécurité personnalisée si nécessaire, la journalisation unifiée et l'audit, la combinaison de plusieurs magasins de données en une seule ressource cohérente. Si vous avez une plate-forme hétérogène, vous n'avez pas besoin d'écrire SDKs, ils ont déjà été écrits dans de nombreuses langues importantes. oData fonctionne très bien avec MS Excel, ce qui est une grande victoire à de nombreuses organisations. En fonction de votre topologie de réseau, il pourrait être moins cher et encore plus rapide à la route sur sur Internet que d'utiliser une ligne louée si vous êtes dans un bureau à distance, ou derrière un pare-feu (sur un site client faire une démonstration, par exemple) .

Pour les grands ensembles de données, les frais généraux de la demande et l'emballage devient moins important. Pour les scénarios de rapports, par exemple. Bien que je ne l'ai jamais conçu quelque chose comme ça, je peux voir où il pourrait être utile, en fonction de votre culture d'entreprise et les ressources disponibles, à consommer OData points de terminaison interne.