The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

.Net Project Layout

So obviously I know just enough to be dangerous but not enough to pull everything together.  I have the following situation.

- Project with my actual object implementation
- Project with my data access

I'm using an interface on my data access layer so that we can implement a different data access implementation later (web services probably).

The problem I have is that my objects are complex enough that it I'm creating and populating an instance of them in the data access layer.  So my data project needs a reference to my object project.  But my objects need to be able to call the data layer so they can tell it to update such and such a value which means they need a reference to my data project.  So now I'm stuck with a circular reference situation.

I'm sure there is a very obvious solution for this..

Shane
Stupid Question = No Real Name :)
Thursday, October 05, 2006
 
 
Basically, move domain object creation into your domain layer.  There's various ways to handle this with factory methods, factory classes, etc. depending on your situation.
Mike S Send private email
Thursday, October 05, 2006
 
 
If the interface is defined on the object layer then the object layer doesn't actually need to know about the data layer does it?  At that point the data layer references the object layer and the object layer just knows it will have an instance that implements it's interface.

This seems to jive with the dependency inversion principle?
Stupid Question = No Real Name :)
Thursday, October 05, 2006
 
 
I ran into this problem just the other day (I had originally intended to have a big DataAccessFacade class that would create my domain objects, but like you said, that's a circular reference).

In the end, I decided to just let my domain objects be "entity classes" (or "active records" I guess is the same concept) and handle their database access themselves. I still have a DataAccess class within my domain model assembly, with helper methods for executing SQL queries and returning a provider-independent DbDataReader, etc.). This might not be the perfect design, but it lets me move forward rather than getting stuck in analysis paralysis. :-)
Jesse Send private email
Thursday, October 05, 2006
 
 
If the Widget class starts to get cluttered with too much persistence logic, I often create a WidgetRepository class (after Evans' Domain Driven Design) which lives in my domain layer and does all the calls to the data access layer for handling persistence of Widgets.
Mike S Send private email
Thursday, October 05, 2006
 
 
> I'm sure there is a very obvious solution for this..

Something like this, perhaps:

1) Data access layer defines whatever interface it needs to create a business object, for example:

interface IDalCreateT<T>
{
  //create List<T> from a SqlDataReader
  List<T> create(SqlDataReader reader);
}

2) Business layer (which defines the business objects of type T):

a) References the DAL (and not vice versa)
b) Implements the IDalCreateT interface and passes an instance of it to the DAL as a parameter to one of the DAL methods

3) DAL now has an IDalCreateT interface, which it can use to create business objects.
Christopher Wells Send private email
Thursday, October 05, 2006
 
 
Or you could define DAL methods like:

void get<T>(out T businessObject)
  where T : whatever interfaces you need T to support in order to build it
{
  ...
}

I don't know much about this topic. The most famous implementation of it is I think http://www.hibernate.org/343.html
Christopher Wells Send private email
Thursday, October 05, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz