2 Cat2
-- MVC - тынЦ , тыНц
(классическое клиент-серверное приложение)
-- Основные паттерны - тЫнц

2 _hike_
MVC, строго говоря, не паттерн, а подход к разработке приложения.
Просто делит программу на 3 части, примерно так:
-- менеджер данных
-- менеджер представления
-- менеджер управления
Нирвана в том, что все три модуля взаимодействуют друг с другом в соответствии с неким внутренним интерфейсом (API) таким образом, что можно заменять их на аналогичные (соблюдая правила вызовов API), не нарушая работоспособность приложения. При этом, реализация этих модулей может быть различной.

PAC - не встречал никогда. Может, это модификация какого-нибудь шаблона из "Основных паттернов"? Тогда, хотелось бы знать, какого именно.

2 _hike_
Если говорить о приложении для работы к БД, то я (когда-то, когда был программистом ;0) делал так:
-- разрабатывал SP (stored procedures) в базе данных, обеспечивающих _все_ необходимые манипуляции с данными, включая запросы select - MODEL
-- собственно интерфейс представлял собой "картинку", необходимую для выполнения пользователем манипуляций с данными - VIEW
-- в приложении присутсnвовали классы, обеспечивающие взаимодействие с БД посредством вызовов определенных SP. Интерактивное взаимодействие осуществлялось путем обращения контролов из форм GUI к этим классам. - CONTROL.
Получилась та самая MVC :0)

Недостатки:
-- необходимость разработки большого количества SP, которое растет нелинейно с ростом функционала БД
-- необходимость разработки достаточно сложного API для взаимодействия классов в приложении

Достоинства:
-- возможность смены СУБД с минимальными затратами (если не считать необходимость разработки SP на новой платформе ;0)
-- строгий контроль доступа к данным - доступ только через SP
-- модульная структура программы позволяет модифицировать нужные модули, не нарушая работоспособности других модулей
-- возможность использования более слабого железа на клиенте, т.к. основной функционал реализован на сервере

Возможности развития:
-- использование менее строгого подхода к обработке данных, т.е SP делать только для сложных обработок и/или для модификации данных
-- CONTROLER можно выделить в отдельную библиотеку и обращаться через COM интерфейс из "тощего" клиента, разработанного на другом языке программирования
-- еще что-нибудь придумать

В общем, все вышесказанное не является ничем таким революционным. Думаю, большинство программистов используют аналогичные подходы.
Удачи.

Книга "Дизайн пользовательского интерфейса" - тЫнц
Достаточно разумная. Рекомендую.

Вдогонку: Еще материалы по проектированию GUI - www.usability.ru

На здоровье.