Hola Leandro, me parece que es medio confuso lo que decís y coincido con
lo que te dicen ambos Carlos.
Hablar cliente-servidor para mi significa hablar de un sistema de 2
capas físicas (tiers) pero estas tranquilamente pueden estar
implementadas en varias capas lógicas (layers). Por eso vos podés tener
un thin client o un fat client, según donde pusiste las capas lógicas si
en el cliente o en el servidor.
Quizás vos estás usando la terminología de distinta forma.
Como ya dijo Carlos Peix, REST no dice nada de en cuantas capas lo vas a
implementar (si querés ver un ejemplo de REST con implementación en
capas fijate en los ejemplos de Ruby on Rails (de la versión 2.0 en
adelante)).
Leí sólo un poco y muy por arriba el link que mandaste de EntityBag (y
tengo muy poca idea de EF) pero yo interpreto que la idea es usarlo en
una aplicación en capas, y fijate que no expone directamente los datos
sino que expone objetos (entidades), que justamente es la idea del
Entity Framework (o cualquier otro ORM).
Además de esto, lo opuesto a una aplicación hecha en capas no es una
data céntrica sino una monolítica.
Tampoco coincido en que sea tan engorroso armar algo en capas, lo que si
puede llegar a ser un infierno es mantener algo que *no* esté hecho en
capas....en todo caso si hay algo que es repetitivo se podrá usar un
generador de código (o habrá un framework que lo solucione).
ObtenerTodosEmpleados(), ObtenerEmpleadorPorRango(),
ObtenerEmpleadosPorArea()....y por qué no
ObtenerEmpleados(Specification) o algo tipo
Repository<Empleados>.Obtener(Specification)
Creo que ahora hay muchísimas herramientas y frameworks que hacen que
desarrollar en capas sea mucho más fácil. Y que algunas capas sea muy
poco o casi nada lo que hay que hacer para tenerlas.
Saludos,
Pedro
