Should Data Access Layer Code go in my business classes

I have a choice of a few methodologies. I am not sure which is best.
Here is the background. I have two classes Employee and EmployeeDataAccess.
Choice #1.
Have the constructor in my Employee Class instantiate an EmployeeDataAccess object. Then load up the fields in my Employee object from the data I obtained from the EmployeeDataAccess object.

Choice #2.
Whenever I need to create an Employee I do something like the following:
Employee emp = new Employee();
EmployeeDataAccess empDB = new EmployeeDataAccess;
empDB.Load(emp);
Choice #3.
Whenever I need to create an Employee I do something like the following:
Employee emp = new Employee();
EmployeeDataAccess empDB = new EmployeeDataAccess;
emp = empDB.Load();
ThanksI put my vote on alternative#3.

Isn't there a risk that someone will then use my Employee class and it will not have any of its data fields loaded? Is this a bad practice?
Would I be better off having one of my employee constructors take an instance of EmployeeDataAccess?
Employee emp = new Employee(new EmployeeDataAccess())
Thanks, as I said in my previous post, I am trying to learn good OO habits.

From the choices you presented I would have to say #3 as well.
However, you should also look into having a business routine that calls the data access instead of calling it directly.
Ex.
Employees class - contains a static routine called Load which returns an employee.
The static routine in Employees class calls EmployeeDataAccess routineto load an employee. Then returns the value returned fromEmployeeDataAccess.Load.
This would let you perform any business logic on the returned value(even deciding not to return a value) without having to includebusiness logic in the EmployeeDataAccess.
Good Luck,
James

In the past I worked a lot with typed datasets in the different tiers but in my current large project we use custom objects instead. Our DAL logic looks a lot like your #3 but has sometimes an override to load only a subset or the top ... elements.
Cutting Edge: DataSets vs. Collections
Grz, Kris.

If I understand you correctly, I think you are getting at what I meant in option #1.
public class Employee
{
load()
... other fields and methods

Employee(employeeID)
{
load(employeeID)
}

public void load(employeeID)
{
EmployeeDataAccess empDB = new EmployeeDataAccess()
Dataset ds = empDB.Load(employeeID)
// take info from data set and load employee fields
}
}
public class EmployeeDataAccess()
{
load()
... other fields and methods

EmployeeDataAccess()
{
// Set Connection String
}
public Dataset load(employeeID)
{
// Connect to DB
// Invoke Stored Procedure
// Disconnect from DB
}
}
I apologize if I am confusing, I am new and confused by all of this.
An example in code would be very helpful.
Thanks
I would recommend that you get yourself a good book to familiarize yourself with the concepts of C# and objectoriented programming from scratch. One book I can recommend is "Visual C# .NET Step by Step" (John Sharp, Jon Jagger / Microsoft Press) which takes you through some of the basics in a graspable manner. I can promise you, that you will be much better equipped to handle the often mind boggling tasks of programming after reading and using this book.
Thanks, I will do that. The other day I ordered:
Maximizing ASP.NET : Real World, Object-Oriented Development
I was told that it has some pretty good coverage of n-tier development. I will pick up the book you recommend as well.