Przyjrzyj się modelom MVC, gdzie Viewer odpowiada UI Layer, Controller odpowiada Business Layer, a Model odpowiada Data Layer (właściwie Data Layer oraz Data Access Layer).
Prosty przykład (spore uproszczenie, mające na celu pokazać ideę):
Załóżmy, że dane trzymasz w bazie danych lub plikach. Budujesz klasę (najczęściej jedną dla każdego źródła danych). Klasa ta na zewnątrz udostępnia tylko metody do korzystania z danych, bez względu na ich źródło. Tylko ona ma prawo wywołać powiedzmy polecenia SQL czy dostać się do plików - właściwie tylko ona powinna wiedzieć, że korzystasz z BD czy plików. To jest twój Data (Access) Layer.
Następnie tworzysz klasę (lub kilka klas) kontrolerów. Obiekt kontrolera łączy w sobie menadżera interakcji z innymi systemami (na przykład obsługa gniazd sieciowych) oraz obsługę zdarzeń tak systemu, jak i samego interfejsu użytkownika. Z zewnątrz zatem wpływają do niego zgłoszenia zdarzeń, na zewnątrz eksponuje tylko stan systemu. Stanem może być na przykład blokowanie okna głównego i pokazanie okna połączenia bez względu na to, jak wyglądają te okna i jaka jest ich klasa). Ważny jest tylko interfejs klasy UI Layer, by udostępniał takie funkcjonalności lub samodzielnie korzystał z interfejsu kontrolera.
Ostatnia grupa klas to UI Layer. Większość środowisk RAD tworzy ją automatycznie, generując dla każdej formy osobne okno. Podstawowa jednak różnica wynika z tego, że środowiska te chcą łączyć w sobie zarówno Viewer, jak i Controller, gdyż sugerują obsługę zdarzeń w ramach samej formy.
Rozwiązaniem powyższego problemu jest, w ramach obsługi zdarzeń, wywołanie metody obiektu odpowiedniego w danej sytuacji kontrolera, a na podstawie zwróconego przez niego stanu ustawienie wyglądu.
Podmieniając Data Layer na inny o tym samym interfejsie, jesteś w stanie zmienić dostawcę danych, bez modyfikowania działania aplikacji. Zmieniając UI Layer jesteś w stanie dostosować wygląd GUI bez zmiany działania aplikacji. Business Layer jest tu kluczową częścią, bo decyduje o formie przetwarzania danych i jego zmiana de facto zmienia aplikację. Warstwa logiki biznesowej rzadko zatem jest całkowicie zmieniana, natomiast rozszerzanie jej pozwala na pracę nad programem, który wciąż wygląda tak samo, wciąż korzysta z tych samych danych, a ma już zaimplementowane (choć jeszcze ich nie eksponuje) nowe funkcjonalności.