Circular dependency

[nyhetsgrupper]

I'm trying to build a .NET application (C#) which I want to seperate
into the classic UI, Business Logic and Data Access layers.
I expected to seperate each layer into different projects and reference
each as required, when I try to do this I run into circular referencing
problems between the projects because the Data Access project
references the Business object project and vice versa.

The examples I have read from varous sources involve passing business
objects to the Data Access Layer to get them populated, normally this
happens in the constructor of the Data Access Layer - the Business
object creates a Data Access Object and passes itself in (as "this").
This is OK but in the examples the Data Access objects and the Business
objects reside in the same project so don't have the circular
referencing problems that I have.

I would be grateful for some help and examples.

 

[Nicholas Paldino [.NET/C# MVP]]

You have two options here. The first would be to have the business
classes and the data access classes in the same assembly (and privatize the
data access, most likely). While I normally agree that a logical boundary
(business layer vs data layer) calls for a physical separation, it doesn't
mean that has to be the case. Your physical separation could be the
namespaces of the classes, for example.

The other option is to factor out interfaces that your classes share
into another assembly, and reference that from your two assemblies, and pass
the interfaces around, not the class instances.

Hope this helps.

 

[ZenRhapsody]

I strive to keep my working business objects and Data layer truely
independent of each other. I also like being able to create business
objects without requiring a database.

To that end, I typically define some basic data structures (either defined
in the data layer or in a 3rd typelib-type assembly) that are filled in the
data layer and passed to the business layer. with this approach, you can
build the data directly in test code to emulate a database.


I've also used the interface approach.

 

[Guest]

I favor the option of separate projects as well. I typically have 3 separate
projects: 1)Data Access Layer, 2)Business Logic Layer, and 3)Business
Objects. Then both the Data Access Layer and the Business Logic Layer
reference the Business Objects project.

 

[nyhetsgrupper]

Thank you all for taking the time to answer. Can you explain in greater
detail what you mean Aaric? Which interfaces does each of your 3
projects expose? Does the Buisness object project keep datatypes only?
No logic? Doesn't that break the OO model to place the logic for an
object outside the object itself?

 

[Guest]

Sure, my business objects only contain datatypes (private fields and their
public accessors) and no logic except for one public method that takes
IDataReader and populates the fields with the data from the datareader,
sometimes I have heard this refered to as data transfer objects (DTO). The
purpose is to be a light weight object for transfering data between layers.

So, the business logic layer gets a request for an object. It then
instantiates the object and passes it down to the data access layer. The data
access layer populates the object by calling the public method and passing in
an IDataReader. Then the data access layer returns the object to the business
logic layer which applies any necessary logic and then returns it to the UI
which initiated the request.

Now, whether or not this breaks the OO model I am not really sure. I would
not think so, but I also would not consider my self proficient in the OO
principles. What do you think or if any one else can provide insight on this
I would gladly welcome the information.

Thanks,
Aaric

 

[nyhetsgrupper]

Thank you Aaric. You aproach seems OK, I think I will go for a similar
solution. You are probable rigth about this not breaking the oo model.
I am not consider my self proficient in the OO principles either.