+1  A: 

One of the reasons people do Persistance Ignorant objects (POCO) is to avoid such a scenario. There is simply no way for the data access layer to have a reference to a class that it doesn't know about - it is much better to have the class not know about the data access.

The only way you can really do this is to implement Get() on User instead of on UserDA. You can do something like this:

public class User {
  IGetFromPresistance<User> _userFetcher;
  public static IList<User> GetMatching(Specification<User> spec) {
    var values = _userFetcher.Find(spec);  //Returns a DataRow or IDictionary<string, object>
    return new User() {
      PhoneNumber = new PhoneNumber(values["phone"].ToString()),
      Name = values["name"].ToString(),
    };
  }
}
George Mauer
How should I change the architecture to achieve a better design?
JMSA
I am a big fan of the way Sharp Architecture does it: http://sharparchitecture.net/ download the files and look for the doc in there - it has a lengthy description of the pattern the process is also described generally in this article: http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspxBasically you have a data access object in the DAL with non-static methods like UserDao.GetById(int id) : User and UserDao.Save(User user). The User doesn't know anything about persistence concerns - it ONLY describes the user business object
George Mauer
Each UserDao is also based on IUserDao. The interface is in the domain layer and the DA layer depends on the Domain (but the Domain does not depend on the DA). If you really need to you can have business objects using an IUserDao and the specific implementation is injected into them from a higher layer. By the way throughout the course of the articles describing this pattern the term DAO and Repository are used somewhat interchangeably though the hardcore DDD guys would argue there is actuall a difference.
George Mauer
+1  A: 

As far as I can understand you have a bidirectional relationship between your DA and Business layer. To solve this problem I suggest that you should have 3 layers instead of two. I mean you should have a Model layer that simply model the DB objects ,then you can derive from model classes in your Business layer and add other behaviors like Save method.

Here's what I mean:

//Model Layer
public class UserModel
{
public virtual string Firstname{get;set;}
}
//DataAccess Layer
public class UserDao
{
List<UserModel> GetAll();
}
//BusinessLayer
public class UserDomainModel:UserModel
{
public UserDomainModel(UserModel user,UserDao dao)
{
_user=user;
_dao=dao;
}
public override string FirstName
{
get
{
return _user.FirstName;
}
set
{
_user.FirstName=value;
}

public void Save()
{
_dao.Save(_user);
}
}
}

I'm using a decorator to combine User and UserDao as a domain model object.

Beatles1692
What you personally do to divide your application among layers while keeping the circular dependency aloof?
JMSA
Actually I don't combine my model with Data access functionality. Model classes doesn't know about DataAccess
Beatles1692