Preventing Circular Reference

Question

I have a wrapper project I created to talk to a 3rd party API.

In another project, lets call it MyBusinessLayer.csproj. It uses this API by adding the wrapper project as a project reference so that it can use various classes to call API methods via HttpRequest / HttpResopnse.

Now I need to do a bulk update by calling a wrapper class called UpdateRequest.cs and loop through each of the records in our database and using some of the fields from each of those records make an API call to update each record.

Problem is this:

1) I want to create like a BulkUpdateRequest.cs in my wrapper project.
2) Problem is that it would have to take a generic list of objects into the constructor. This generic list of objects (the records I'm pulling from our database), the Object's .cs resides in MyBusinessLayer.csproj since it represents the table and instance of each record for that table in my DB. If I send a generic list of those objects to my wrapper. BulkUpdate.cs class that does the looping and sending of the request to update all those records in the generic list, I've just introduced a circular reference because MyBusinessLayer.csproj is referencing MyWrapperProject.csproj. And then MyWrapperProject.csproj is referencing a class in MyBusinessLayer.csproj because it's taking in a list of generic object instances that represent records in our DB.

So I guess how is the best way to keep a circular reference from happening? I guess I could instead create the BulkUpdate logic in MyBusinessLogic.csproj and that way, I'm jsut referencing the UpdateRequest.cs and doing the loop in some class I create in MyBusinessLayer.cs and only using the UpdateRequest.cs class from our wrapper project and not sending any of the MyBusinessLayer classes to that wrapper project.

I hope this makes sense...

Answer 1

I am going to operate under the assumption that the 'generic list of objects' you refer to are of some Type that is defined in your MyBusinessLayer project and not System.Object. I think you say that.

A solution would be to make both MyBusinessLayer and MyWrapperProject depend on a third project (MyAbstractDefinitions) which contained IDatabaseObject.cs and any other interface types derived from IDatabaseObject. Neither MyBusinessLayer nor MyWrapperProject should depend on the concrete implementation of this object that represents records in the database. Both projects should depend on an abstract definition.