I've seen a lot of custom data access layers—some good and some not so good. Writing a custom data access layer is busywork that generally moves data from a logical schema into a conceptual collective of objects. The mismatch between the needs of the database and the needs of the solution is referred to as an impedance mismatch.
The ADO.NET Entity Framework handily plays the role of data access layer, letting you focus on the solution rather than a database schema. The Entity Framework converts the database's view of the data, the logical schema, normalized for the database's needs into a conceptual model representing your problem-space's needs.
In my article "Writing LINQ Queries with the Entity Framework," I covered using LINQ to Entities. Here we'll explore Entity SQL. LINQ to Entities and Entity SQL are competing technologies. You probably don't need to learn both, but familiarity with both will help you to decide which approach may work best for you in a given scenario.