Mentoring techniques

Yesterday while at work I was asked by a junior developer what type of data access layer my team is using on our project.  He was wondering about the use of data sets or business objects.  Do we use inline SQL or stored procedures.  So I sat with him and had a short conversation about his inquiries.  After he left, I got to thinking, I better go see what he's working on before he tries to kill a mosquito with a canon.  Good thing to.  His initiative on his application was to take some ideas from a data access layer that another senior developer had wrote, and try and improve on it.  I love the young sponges in the world.  They just want to learn, push their abilities, and absorb as much knowledge as they can.  But where do you draw the line with them?  The data access layer he was going to try and enhance was solid, and has pasted the test of time.  Its been implemented in several other applications as well.  I'm all for enhancing and trying to find a better way, but the path he was going down I was skeptical about.  It is my job after all to set him up for success.  So I worked through some scenarios with him.  I asked him how would you unit test your data layer?  Would it be easier to maintain your design, or the current design?  Does your design or the current design make more logical sense?  My goal with him was to try and get him to understand the challenges that he'll face instead of telling him to just do it this way and be bombarded with a series of "what if's" and "ya but's".  After he started to see the light, we talked about maybe some other technologies he could use instead of rolling his own data layer.  One technology we talked about was the use of the ADO.NET Entity Framework.  It basically builds the entire data layer for you, but its still cutting edge technology and maybe hasn't yet pasted the test of time yet.  What other techniques do you use?