Una cosa que debes entender primero es que OOP no es sinonimo de 3-tiers (3 capas). De hecho, tu podrias perfectamente implementar un sistema de 3 capas sin usar OOP y tambien programar un sistema completo usando OOP y con solo 1 capa.
OOP es un paradigma de programacion que utiliza clases y objetos para representar elementos de software e interactuar con ellos, en contraposicion al paradigma de la programacion procedimental donde tu programas solo acciones que pueden ser invocadas en un momento dado pero que no almacenan informacion de estado (a diferencia de OOP donde eso si puede suceder).
La programacion en 3 capas o n-tier (porque no necesariamente tienen que ser 3) se refiere a una tecnica en donde una app se separa en dos o mas capas "funcionales" que trabajan (normalmente) de forma desacoplada e independientes una de la otra. Por ejemplo, en una APP de escritorio tipica tu tienes codigo que maneja la interfaz visual (formularios, reportes, etc), codigo que realiza las operaciones propias de la app (por ejemplo, calcular la nomina, validar datos de entrada, generar data para reportes, etc) y luego tienes codigo que maneja el almacenamiento y recuperacion de datos, todo metido dentro de una misma app.
La programacion en 3 capas lo que te dices es: separa las funciones en componentes separados:
a) Capa de presentacion: donde solo manejas todo lo relativo a presentar formularios, menus, interaccion del usuario con la pantalla, reportes, etc. Este es tu programa "principal" y el componente con el que interactuaria el usuario directamente.
b) Capa de negocios: aqui tienes todo el codigo que implica "inteligencia de negocios": validaciones, operaciones de transformacion de datos, obtencion y preparacion de datos para reportes, etc. Basicamente esta capa funciona como intermediario entre la capa de presentacion (la interrfaz visual) y la capa de datos. Esta capa se puede implementar de muchas formas, siendo las mas tipicas un DLL ActiveX, un servicio TCP/IP o un servicio Web (via HTTP requests, bien sea SOAP o REST).
c) Capa de datos o almacenamiento: aqui es donde tiene el codigo que permite almacenar y recuperar datos. Tener una capa separada de datos te permite ciertos beneficios, como por ejemplo, no depender de un motor especifico de BD o realizar ciertas operaciones antes y/o despues de una operacion de acceso a datos. Al igual que en el caso anterior, esto puede ser implementado de distintas formas. En mi caso, por ejemplo, suelo utilizar stored procedures como una "capa de datos" entre mi app y el SQL Server, pues esto me da la ventaja muchas veces de implementar cambios sin tener que recompilar mi capa de negocios. Entonces, mis apps nunca hacen INSERT, UPDATE o SELECT directamente sobre la BD sino que en su lugar invocan un SP para cualquier operacion de datos necesaria. Es mas trabajo (pues debes programar y mantener los SPs) pero las ventajas que me ha dado con el tiempo hacen que valga 100% la pena el esfuerzo extra.
Cuando trabajas con aplicaciones tradicionales o "fat client", a nivel personal generalmente utilizo solo 2 capas: mi app (que maneja solo la interfaz visual) y la capa de negocios-datos implementada en forma de Stored Procedures. Sin embargo, no es una regla escrita en piedra y muchas veces, sobre todo en procesos de larga ejecucion, traslado parte de las funciones de negocios a la capa de presentacion porque SQL Server no maneja muy bien los stored procedures que tardan mucho en ejecutarse. En estos casos aprovecho todas las bondades que ofrece VFP para el procesamiento de datos.
Lo mismo pasa cuando trabajo con aplicaciones web. En este caso la misma tecnologia web te obliga a tener al menos 2 capas: la de presentacion (en forma de tu HTML / JS / CSS que ejecuta en el browser) y la de negocios/datos (en la forma de un web service SOAP o REST). En mi caso, tipicamente añado una tercera capa de datos en forma de Stored Procedures.
Saludos
Victor Espina