Bueno ya en serio, creo que tu post es bastante claro al dejar ver que no te caen muy bien eso de las ‘capas’. Me hubiera gustado que explicaras o sugirieras alguna alternativa a este modelo.
Ya tengo rato programando mis aplicaciones con este modelo, y para ser honestos me ha pasado mas de una vez que.. tengo alguna clases o metodo en mi capa de negocio que a su vez manda a llamar a la capa de datos, sin ejecutar ninguna ‘logica de negocio’, entonces es cuando surge la confusion y me pregunto si acaso tiene sentido tener a esa capa de negocios como intermediario entre mi capa de presentacion y mi capa de datos.

Aun asi, yo creo que el problema con las capas no es el modelo en si, sino las personas que tratamos de ejecutar dicho modelo. Si nomas nos ponemos a programar y hacer capas y capas solo por que asi nos enseniaron que debiamos de programar, vamos a terminar con un serio problema de arquitectura y dependencia entre capas. En todo momento se tiene que estar conciente de lo que se esta haciendo y para que lo estamos haciendo.

En mi punto de vista, la idea fundamental del modelo de capas es aplicar la Separacion de Responsabilidades. Tomando como ejemplo la Capa de Datos, responsable de persistir nuestras entidades en una base de datos, un archivo, etc. La verdad yo encuentro muy pero muy util tener toda esa logica de persistencia en un solo lugar, es mas facil de mantener, mas facil de extender, mas facil de reutilizar. 
Y bueno, como dices, a lo mejor ya no tiene sentido tener una capa de datos, con tanto ORM ahi afuera. Sin embargo, yo veo a esos ORM como una Capa de Datos en si, cuya unica responsabilidad es accesar datos y persistirlos.

Hablemos de MVC, se tienen los Modelos, que son nuestros objetos de negocio, ahi vive la logica de negocio, de validacion, las llamadas a nuestra capa de datos ( o en su caso un ORM), se tienen las Vistas, meramente logica de presentacion, se tienen los Controladores, los cuales canalizan y conectan nuestros modelos con las vistas. Para mi eso suenan como ‘capas’, cada uno responsable de cosas diferentes. 

En conclusion, creo que el modelo de capas carece de sentido si nomas haces capas por que asi te dijeron que se tenian que hacer. Sin embargo creo que es totalmente valido si lo que quieres es organizar tu codigo y separar las responsabilidades de tus clases para tener un mejor control, manejo y organizacion de las mismas.

Saludos

La mayoria de los desarrolladores nuevos solo les enseñan a diseñár bases dedatos con el modelo “Relacional” y no a diseñar con el modelo “Entidad-Relacion” (he visto muchos diagramas que según son Entidad-Relacion y ni relacionales son). Estando diseñada la base de datos en este modelo la capa de negocio se diseña de acuerdo a las entidades y el desarrollo en equipos de trabajo y sobre todo el mantenimiento queda mucho mas sencillo a que si se hace una aplicación monolítica. Las aplicaciones monoliticas siempre funcionaran perfectas para un desarrollador unico o desarrollos donde cada miembro del equipo de trabajo tiene asiganda una parte del codigo y nadie mas lo toca.

Malamente a veces a la capa de negocios le dicen una clase que contiene todo el código o los metodos mapeados a la base de datos como si fuera el ORM y así no es el modelo.

Para revisar sobre arquitecturas .NET pueden checar http://apparch.codeplex.com/

Para mi gusto la aplicacion si debe de tener una estructura de capas, aunque ya se que las formas de desarrollo son como la religion, jejeje

I’m happy to follow up and let you know that the issue with Visual Studio 11 you describe is fixed in the latest official 2011 Q3 release of JustCode. Please give it a try and let us know what you think.

Kind regards,
Vladi
The Telerik team