Utilisation de VS 2008 & .NET 3.5 SP1:
J'utilise WCF pour permettre aux clients de se connecter à un service qui lit et écrit des entrées de base de données à l'aide d'un cadre d'entité. Par défaut, les entités générées automatiquement à partir de la base de données ont l'attribut Datacontract appliqué.
Malheureusement, de nombreux champs sont exposés ne sont pas destinés à la consommation par le client (c'est-à-dire des enregistrements d'qui accède quelles données, etc.) et pour des raisons de sécurité, je préfère les empêcher d'être exposé. Y a-t-il un moyen d'éviter les classes de cadre d'entité d'être exposées de cette manière?
note : Ce n'est pas un duplicata de Comment empêcher les propriétés privées dans les entités .NET d'être exposée comme publique via des services? . Dans cette question, l'utilisateur souhaite afficher certains champs, alors que j'aimerais que l'entité ne soit pas exposée comme datacontrice du tout.
Merci d'avance.
3 Réponses :
Nous utilisons des classes séparées pour les objets Datacontract. Nous avons une interface avec une méthode, TOCONTRAIRE () et toutes nos entités implémentent cette interface dans un fichier de classe partielle. C'est un travail supplémentaire, et c'est la chaude, mais il semble le moyen le plus simple d'obtenir la séparation et la granularité du contrôle dont nous avons besoin.
Je vois essentiellement deux choses que vous pouvez faire:
marc
Merci, Marc_s. En ce qui concerne le point 1 ci-dessus, comment supprimer manuellement l'attribut [Datamember] de ces éléments générés automatiquement à partir de la base de données? Cela nécessitera-t-il une reprise manuelle chaque fois que je mettez à jour le modèle de la base de données?
Malheureusement, oui, j'ai bien peur qu'il n'y ait pas de moyen automatique de supprimer ces attributs [Datamember] que je connais. Par conséquent, l'idée de classes de WCF séparées que vous contrôlez pleinement.
Savez-vous que vos entités n'ont pas besoin de mapper une sur une avec la base de données? En particulier, vous pouvez laisser des colonnes, voire des tables entières qui ne sont pas pertinentes.
Le modèle d'entité est censé être un modèle conceptuel. Vous pouvez facilement créer un ensemble d'entités pour une exposition à un ensemble de clients (services Web, peut-être), et un autre ensemble, mappage de la même base de données, destiné à un client différent (application Web, peut-être).
D'autre part, je vous recommande toujours d'exposer déjà des objets de cadre d'entité via un service Web. Microsoft expose malheureusement aux propriétés dépendantes de la mise en œuvre en les marquant avec [Datamember]. Je viens d'essayer cela avec un simple service renvoyant un vendeur de vente d'aventureworks. Mon client a reçu des versions proxy des types EF suivants:
Ce ne sont pas des choses que vos clients ont besoin de savoir.
Je préfère exposer les objets de transfert de données et copier les propriétés de l'une à l'autre. De toute évidence, cela est mieux fait par la réflexion ou la génération de code, que par la main. Je l'ai fait par la génération de code dans le passé (modèles T4).
Une option que je n'ai pas essayée est Automapper .
Merci pour votre réponse, John. Oui, je suis conscient que les entités n'ont pas besoin de mapper une seule et peuvent modéliser un sous-ensemble du modèle conceptuel, mais je ne pense pas que cela me donnera le résultat que j'estime. Voici un exemple: supposons que j'ai une table de comptes dans un système de comptabilité et que je souhaite auditer les opérations effectuées sur lesquelles des comptes. Je dois exposer des champs de la table de compte, mais je ne veux pas que mon potentiel fraudeur de voir quelles informations je suivent sur ses actions. Continué dans le prochain commentaire ...
... suite du commentaire précédent. Lorsque le client appelle une fonction, je souhaite créer un enregistrement et insérez-le dans ma table d'audit pour le suivi et l'analyse. J'aimerais avoir les deux accompagnés via EF (qu'ils soient dans les mêmes conteneurs d'entités ou distincts ne sont pas importants pour moi). Malheureusement, tout ce que je définis dans le cadre du modèle de données est exposé sous forme de Datacontract.
Donc, n'exposez pas le modèle de données. Exposez un modèle de données plus petit - celui que vous voulez exposé. N'exposez pas le même modèle sur le fraudeur potentiel que vous le faites sur le système d'audit.
Ahh ... la lumière continue. ;) Le problème n'est pas avec la technologie qu'il est avec ma composition de services - trop monolithique. Merci John.
+1 Good Info. MODApper est assez utile à cette fin. Je l'ai utilisé avec succès dans une variété d'applications de cartographie de données.
Cela peut être similaire à une autre postation qui n'a pas été résolue complètement: «Frame-entité de la WCF et ADO», Stackoverflow.com/questions/828302/wcf-and-ado-entity-Framew ork
Je suis d'accord avec la réponse sur le lien "WCF et ADO Entity Framework" que vous avez donné. Ou vous pouvez mettre en œuvre une sorte de motif de référentiel.
@Nath - Je suis certainement d'accord avec la réponse sur le "Frame-entité de la WCF et de l'ADO", mais malheureusement, cela ne résout pas mon problème. Le premier point de la réponse est "Générer automatiquement des entités-cadres d'entités", qui exposeront les données que je souhaite garder privées en tant que Datacontranciers. Un modèle de référentiel aurait le même problème s'il était soutenu par un modèle EF généré ainsi également - à moins que je ne manque quelque chose?
Avec les classes que vous pouvez partager à WCF, vous n'exposeriez que des éléments du modèle que vous souhaitez sur le côté WCF, et lorsque vous êtes arrivé à un .save (la myentité) dans le référentiel, vous pouvez remplir vos enregistrements d'audit.