Re: Circular dependency

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.


Aaric wrote:
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@xxxxxxxxx" wrote:

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?


Aaric wrote:
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@xxxxxxxxx" wrote:

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.





.

Relevant Pages

  • Re: 3-tier development
    ... Our business and data access layer code runs on an application server and so ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: project references when building N-tier apps
    ... Extract business objects such as User into a third assembly ... which you then reference from both> Business.dll and DataAccess.dll. ... to call the data access layer and provide the above mentioned user.Save ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Circular dependency
    ... Then both the Data Access Layer and the Business Logic Layer ... I expected to seperate each layer into different projects and reference ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Circular dependency
    ... The first would be to have the business ... classes and the data access classes in the same assembly (and privatize the ... I expected to seperate each layer into different projects and reference ... happens in the constructor of the Data Access Layer - the Business ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Circular dependency
    ... the business logic layer gets a request for an object. ... instantiates the object and passes it down to the data access layer. ... I expected to seperate each layer into different projects and reference ...
    (microsoft.public.dotnet.languages.csharp)
Loading