Calling your queries (even if querying via EF) directly from the UI layer is... EPIC FAIL!!!

Is there any way I can negative-kick this article?

I think different kinds of applications have different priorities. Assuming every application has to be a multiple tier architecture is a failed assumption. But generally any widely used application that will be updated and released many times for more than the most brief period should be at least be modular enough to be flexible. A LINQ layer, perhaps a DataContext in a class library that features supporting classes to query the LINQ DataContext may be a sufficient data access layer. But I agree that calling into the DataContext directly from the UI layer is nearly always bad form.

When I throw together QA pages to simply display data in the staging and production environments I do directly bind them to tables in the database to completely bypass any business logic or complications in the data access layer in order to hopefully reveal the root cause of a bug. Still, I do like to lock down the database to only have EXEC rights on stored procedures and not even allow read access on the tables. Lately the projects I am on do not allow for that level of control in the data access layer. In the last project I actually used SubSonic. At least it provides a good level of compile-time protection because I always made use of the constants for the tables and column names in the queries.

No offense but I'm not a big fan of this idea either. Maintaining an application would be a nightmare.

Tagged appropriately -- too many folks throw business logic, data access, etc. into their views. This encourages what is generally an all-too-common bad idea.