2012-06-28 3 views
0

J'ai créé une base de données (SQL Server 2008 Express) et créé des entités LINQ to SQL (appelées LinqEntitiesDataContext) en utilisant le concepteur OR dans Visual Studio 2010. J'ai ensuite créé un référentiel interface IRepository de classe et associée, contenant un tas de méthodes CRUD sympas et simples qui fournissent un accès significatif aux entités de données. Par exemple, il y a une méthode:Utilisation d'OData avec le modèle de référentiel

IQueryable<User> QueryUsersByType(UserTypeEnum userType) 

et un autre:

void CreateUserWithDefaultType(User user) 

Maintenant, je veux faire de ce référentiel disponible « à travers le fil » et que vous souhaitez utiliser WCF Data Services (OData) pour fournir un accès . Mais chaque exemple d'OData que j'ai vu finit par fournir un accès direct aux entités elles-mêmes (par exemple l'entité Utilisateurs). Pour ce faire, implémentez IUpdatable, puis créez un service de données WCF qui fait référence à cette classe de contexte de données. Dans mon cas, cela voudrait dire rendre LinqEntitiesDataContext IUpdatable et l'utiliser comme type de service - ce qui évite complètement d'utiliser ma classe Repository.

Je sens que je dois faire le service de données exposer mon dépôt:

DataService<Repository> // *Not* DataService<LinqEntitiesDataContext> 

mais je dois faire mon dépôt mettre en œuvre IUpdatable, en évitant les appels à mes méthodes de mise à jour existantes (par exemple CreateUserWithDefaultType)

Qu'est-ce qui me manque ici? Existe-t-il un bon exemple de comment faire cela correctement, exposant la couche Repository plutôt que la couche d'entité?

Répondre

3

Je pense que @Bull était sur la bonne voie ici, mais je veux construire une réponse un peu plus. Comme il l'a dit, OData est principalement conçu pour fonctionner avec des entités, pas des méthodes prédéfinies. Par exemple, pour atteindre le premier de vos exemples, vous voudrez simplement exposer un IQueryable of User, ce qui permettra à n'importe quel client OData de former des URL telles que http://yourdomain/Users?$filter=UserType eq Administrator. Si vous utilisiez le client WCF Data Services, il existe un fournisseur LINQ qui vous permettrait de faire quelque chose comme context.Users.Where(u => u.UserType == "Administrator"). (Notez également que les services de données WCF ne prennent actuellement pas en charge les énumérations dans nos modèles de service.)

De même, la seconde méthode serait typiquement un POST à ​​http://yourdomain/Users (le même IQueryable de User que nous avons vu dans le premier exemple) et vous définissez le type par défaut sur le modèle ou dans la base de données.

Si vous voulez vraiment utiliser votre dépôt, vous seriez probablement mieux loti manipulation du fournisseur de services de données complet personnalisé comme décrit dans le blog de Alex: http://blogs.msdn.com/b/alexj/archive/2010/01/07/data-service-providers-getting-started.aspx

Point final - nous espérons rendre nos fournisseurs publics en le futur proche; Cela simplifierait grandement ce que vous essayez d'accomplir ici. Nous considérerons ce post comme un autre compte pour l'importance de cette fonctionnalité particulière.:)

HTH, Mark

+0

Hmmm, cela signifie que je ne peux pas implémenter une bonne interface propre à mon modèle de données une seule fois et que les consommateurs de services en bénéficieront. Au lieu de cela, chaque composant de ma couche logique métier devra travailler au niveau de l'entité, appliquer des filtres, développer des clés étrangères, implémenter la pagination, etc. Puis-je utiliser Service Operations pour faire ce que je veux? un gâchis?! – MarkH

+0

Certaines des choses que vous voulez faire peuvent certainement être faites du côté serveur. La pagination est triviale du côté serveur si vous travaillez avec le fournisseur EF, et ce n'est pas trop difficile dans le cas contraire. Pré-appliquer des filtres et étendre les clés étrangères est possible, vous devrez peut-être travailler plus dur pour y arriver. Les Opérations de service seront probablement capables de faire tout ce que vous voulez, mais cela risque d'entraîner des dégâts. Morale de l'histoire: nous devons donner la priorité à ces fournisseurs publics. –

+0

Ok, pas ce que je voulais entendre, mais merci pour vos commentaires Mark. Je vais continuer avec OData en tant qu'interface entre nos couches d'architecture car cela correspond à d'autres façons. – MarkH

0

Je pense qu'il vous manque l'image. OData est là pour exposer vos entités en tant que flux. OData est aussi appelé WCF Data Services et le bon endroit pour obtenir l'image de base sur ODATA/WCF Data Services est ici:

  1. tutoriels de démarrage rapide de msdn http://msdn.microsoft.com/en-us/library/cc668796
  2. exposition des données comme service. http://msdn.microsoft.com/en-us/library/dd728286
+0

Juste quelques corrections mineures à cette réponse - OData est non seulement là pour exposer des entités comme les aliments, mais qui est certainement l'utilisation le plus courant. En outre, WCF Data Services est l'implémentation de Microsoft OData (un protocole). Nit mineur, mais OData est en cours de standardisation alors que WCF Data Services ne sera pas standardisé. (Cela implémentera simplement une norme.) –

+0

Merci pour cela :) – Bull

Questions connexes