Do you see it as tight coupling that my business service class opens a SqlConnection ?
Actually a business service should not be aware of the concrete dataprovider?!
public class UnitService:
public void DeleteUnit(Unit unit)
{
using (SqlConnection con = new SqlConnection());
using (TransactionScope trans = new TransactionScope())
{
con.Open();
_unitDataProvider.Delete(unit,con);
_employeeDataProvider.UpdateEmployees(con);
trans.Complete();
}
}
Your qustion is very subject to opinion...
I love to abstract code and uncouple everywhere possible. The question, as always, is that of time and requirements.
For a small simple project that does not require extensive Unit Testing within the Business Tier, your coupling although does not necessarily follow best practice may be exactly what the customer/end-user requires, and may allow you to provide the software in a more timely fashion.
For a larger/more complex/etc project it may be best to abstract the persistance layer.
It is simply not feasible to follow best practices, best design patterns, and best coding principles for every line of code you write. I've found the authors of such books quite often mention the patterns as potentially surplus to requirements and should simply be used as a tool, when needed.
Hope that helps?