Tiers and Circular References

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I want middletier objects and data access objects in different namespaces.

I want the middle tier object to get a reference to the data access object
and pass itself as a parameter to the data access object's constructor,
accordingly the constructor of the data access object must declare a datatype
of the Middle tier object.

The Middle Tier declares a project reference to the Data Access Project to
create the Data Access Object.

When I try to establish a similar reference to the Middle Tier within the
Data Access Project, I get " A reference to Middle Tier could not be added.
Adding this project as a reference would cause a circular dependency."

TIA, doyle
 
Doyle said:
I want middletier objects and data access objects in different namespaces.
Click to expand...

No problem.
I want the middle tier object to get a reference to the data access object
and pass itself as a parameter to the data access object's constructor,
accordingly the constructor of the data access object must declare a
datatype
of the Middle tier object.

The Middle Tier declares a project reference to the Data Access Project to
create the Data Access Object.
Click to expand...

Ah, now you're talking two separate assemblies, in addition to separate
namespaces.
When I try to establish a similar reference to the Middle Tier within the
Data Access Project, I get " A reference to Middle Tier could not be added.
Adding this project as a reference would cause a circular dependency."
Click to expand...

Right, obviously. This is not possible. You should rearrange your classes
in the assemblies (or even merge them) so that dependencies all work "in
one direction".

I don't feel I know enough about your specific situation, but a common
solution in similar situations would be to have the data access class and
a base class for the middle tier object in one assembly and let the data
access class work only with the base class. Then the middle tier class
could be in a different assembly, derived from the base class, and the
directions or dependencies would be fine. Like this:

Classes in assembly "data":

class DataAccessObject {
public DataAccessObject(MiddleTierObject middleTierObject) {
// do something
}
}

// Maybe this would even be an interface only? And in the real
// world, it might not be called MiddleTierObject because the
// data assembly really doesn't know or care about any middle
// tier. Just to make things clear here.
abstract class MiddleTierObject {
}

Classes in assembly "middletier":

class MyConcreteMiddleTierObject : MiddleTierObject {
}


Oliver Sturm
 
Back
Top