"Soul Vaccination" for Data Access Layers

Sorry, but I have to play the devil's advocate...Jeremy Miller recently blogged on Quarantining ADO.NET code to a reusable, separate layer; I couldn't agree more. I've been tasked at work with finishing an ASP.NET application that was written by subcontractors that - well, let's just say I think the result would've been different had it not been subcontracted. One of my biggest peeves with the application is that, with my TDD enlightenment, it's nearly impossible to unit test anything. It very well may not pass DataSets around, but since the ENTITIES are not really ENTITIES (no use of ASSOCIATIONS here folks), the application might as well just pass on the low-level System.Data objects because every action results in at least 2 or more database trips.

Therein lies my concern: over-, and incorrect, use/implementation of O/R persistence. My fear is that O/R persistence is becoming a buzzword or hypeword and that they'll go the route of Web Services. I'm guilty of it myself, I'll readily and openly admit it. I've uttered the phrase "man, if project XYZ were using NHibernate, development would be so much easier and it would be testable blah blah blah" many times and not just for the project that I'm on right now. O/R persistence frameworks empower developers and "with great power comes great responsibility"; we need to be responsible and know when the time is right to employ an O/R framework and when a well-crafted DAL will suffice.

So, in summary, I completely agree with the point of Miller's post: DAL code should be abstracted and encapsulated at a level as low as possible to minimize the possibility of falling into the fate of the 900 ASP file application he mentioned. However, an O/R framework should not be the end-all-be-all solution. If anything Newkirk and Vorontsov's TDD book is a testament to what can be done with a well designed and tested application.