Tiers and Circular References

[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

 

[Oliver Sturm]

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

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.

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."

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