Tiers and Circular References

[Doyle]

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]

Doyle wrote:

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 DataAccessObjec t {
public DataAccessObjec t(MiddleTierObj ect middleTierObjec t) {
// do something
}
}

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

Classes in assembly "middletier ":

class MyConcreteMiddl eTierObject : MiddleTierObjec t {
}
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)