Encapsulation Considerations
In ASP.NET, I try to develop in a "black box," often trying to keep the dependencies with methods small. This technique creates a low "fan-in" or loose coupling that makes the code easier to maintain in the future. With that said, there can be some grey lines when it comes to this arena. For instance, when creating methods, I like to pass in object-references:
public IEnumerable<LinqClass> GetResults(Customer customer)
Rather than:
public IEnumerable<LinqClass> GetResults(int customerKey, bool isPreferred)
{
}
This is because each of the parameter details are stored in the customer object, whereas anytime the criteria changes for GetResults, it requires the developer to break the interface of the method. However, the approach I prefer doesn't work well with some of the featured controls, like the ObjectDataSource. The ObjectDataSource looks to pass in primitive data, with a few exceptions.
Sometimes I wonder just what is the right level of encapsulation. For instance, suppose I had this method:
public void LoadCustomers(GridView grid)
{
CustomerBAL bal = new CustomerBAL();
grid.DataSource = bal.GetCustomers();
grid.DataBind();
}
This method encapsulates what work is being performed on the grid, while allowing multiple grids to be called with this method (if that is a good thing in this scenario). However, I think maybe doing it this way:
public void LoadCustomers()
{
CustomerBAL bal = new CustomerBAL();
this.gvwCustomers.DataSource = bal.GetCustomers();
ths.gvwCustomers.DataBind();
}
This encapsulates what the action is performed against (I don't need to know that it's binding to a grid), but it's not as flexible because it only happens for one grid control, which I think in most situations is better.
But I don't really know which one is better in this situation, but I know one thing; I think I'm overthinking it too much 
!! Any opinions on the subject, or other examples you would like to share?