2009-03-23 15 views
0

J'ai un projet wrapper que j'ai créé pour parler à une API tierce.Empêcher la référence circulaire

Dans un autre projet, appelons-le MyBusinessLayer.csproj. Il utilise cette API en ajoutant le projet wrapper en tant que référence de projet afin qu'il puisse utiliser diverses classes pour appeler des méthodes API via HttpRequest/HttpResopnse. Maintenant, je dois faire une mise à jour en vrac en appelant une classe wrapper appelée UpdateRequest.cs et faire une boucle dans chacun des enregistrements de notre base de données et en utilisant certains des champs de chacun de ces enregistrements effectuer un appel API pour mettre à jour chaque enregistrement .

problème est le suivant:

1) Je veux créer comme un BulkUpdateRequest.cs dans mon projet d'emballage.
2) Le problème est qu'il devrait prendre une liste générique d'objets dans le constructeur. Cette liste générique d'objets (les enregistrements que je tire de notre base de données), le .cs de l'objet réside dans MyBusinessLayer.csproj car il représente la table et l'instance de chaque enregistrement pour cette table dans ma base de données. Si j'envoie une liste générique de ces objets à mon wrapper. BulkUpdate.cs classe qui fait la boucle et l'envoi de la demande pour mettre à jour tous ces enregistrements dans la liste générique, je viens d'introduire une référence circulaire parce que MyBusinessLayer.csproj fait référence à MyWrapperProject.csproj. Et puis MyWrapperProject.csproj fait référence à une classe dans MyBusinessLayer.csproj, car il s'agit d'une liste d'instances d'objets génériques qui représentent des enregistrements dans notre base de données.

Alors je suppose que la meilleure façon de garder une référence circulaire est de se passer? Je suppose que je pourrais plutôt créer la logique BulkUpdate dans MyBusinessLogic.csproj et de cette façon, je suis jsut référençant le UpdateRequest.cs et faire la boucle dans une classe que je crée dans MyBusinessLayer.cs et seulement en utilisant la classe UpdateRequest.cs de notre wrapper projet et n'envoyant aucune des classes MyBusinessLayer à ce projet wrapper.

J'espère que cela a du sens ...

Répondre

4

Je vais fonctionner sous l'hypothèse que la « liste générique des objets » dont vous parlez sont d'un certain type qui est défini dans votre projet MyBusinessLayer et non du système. Objet. Je pense que tu dis ça.

Une solution consisterait à faire dépendre à la fois MyBusinessLayer et MyWrapperProject d'un troisième projet (MyAbstractDefinitions) contenant IDatabaseObject.cs et tout autre type d'interface dérivé de IDatabaseObject. Ni MyBusinessLayer ni MyWrapperProject ne doivent dépendre de l'implémentation concrète de cet objet qui représente les enregistrements dans la base de données. Les deux projets devraient dépendre d'une définition abstraite.

+0

Merci, c'est logique. Le troisième projet peut logiquement être "Data Loads" ou quelque chose à cet effet où vous ajoutez les deux projets (MyBusinessLayer.csproj & MyWrapper.csproj) et ensuite créer une application console pour faire la logique pour tout type de mise à jour ou de chargement de données. – user72603

+0

Ou, autant de projets font: 1. données/entités (éventuellement avec des interfaces) 2. Prestataire/Services (Votre opérations CRUD) 3. Mon application (utilise les deux) –

+0

Je ne suis pas lourd dans Interfaces pourtant si essayer d'imaginer l'IDatabaseObject.cs quand nous avons déjà une DL et en imaginant cela en ce qui concerne les projets BL et wrapper dans un troisième projet. – user72603

Questions connexes