Best "pattern" for Data Access Layer to Business Object

If the configuration you've got works now, why mess with it? It doesn't sound like you're identifying any particular needs or issues with the code as it is.

I'm sure a bunch of OO types could huddle around and suggest various refactorings here so that the correct responsibilities and roles are being respected, and somebody might even try to shoehorn in a design pattern or two. But the code you have now is simple and sounds like it doesn't have any issues - i'd say leave it.

I've implemented a DAL layer by basically doing what NHibernate does but manually. What NHibernate does is create a Proxy class that inherits from your Domain object (which should have all its fields marked as virtual). All data access code goes into property overrides, its pretty elegant actually.

I simplified this somewhat by having my Repositories fill out the simple properties themselves and only using a proxy for Lazy loading. What I ended up is a set of classes like this:

public class Product {  public int Id {get; set;}  public int CustomerId { get; set;}  public virtual Customer Customer { get; set;}}public class ProductLazyLoadProxy {  ICustomerRepository _customerRepository;  public ProductLazyLoadProxy(ICustomerRepository customerRepository) {    _customerRepository = customerRepository;  }  public override Customer {    get {      if(base.Customer == null)        Customer = _customerRepository.Get(CustomerId);      return base.Customer    }    set { base.Customer = value; }  }}public class ProductRepository : IProductRepository {  public Product Get(int id) {    var dr = GetDataReaderForId(id);    return new ProductLazyLoadProxy() {      Id = Convert.ToInt(dr["id"]),      CustomerId = Convert.ToInt(dr["customer_id"]),    }  }}

But after writing about 20 of these I just gave up and learned NHibernate, with Linq2NHibernate for querying and FluentNHibernate for configuration nowadays the roadblocks are lower than ever.

Most likely your application has its domain logic setup in transaction scripts. For .NET implementations that use transaction script Martin Fowler recommends the usage of the table data gateway pattern. .NET provides good support for this pattern because the table data gateway pattern is great with record set, which Microsoft implements with its DataSet-type classes.

Various tools within the Visual Studio environment should increase your productivity. The fact that DataSets can easily be databound to various controls (like the DataGridView) makes it a good choice for data-driven applications.

If your business logic is more complex than a few validations a domain model becomes a good option. Do note that a domain model comes with a whole different set of data access requirements!