Архитектура приложения

SugarApplication не расширяется, но зато в SugarController есть метод preProcess(), в котором до вызова контроллера можно выполнить дополнительные проверки или инициализации.
Когда приходит запрос приложение получает контроллер от ControllerFactory, который основываясь на строке запроса выбирает нужный.
Эта фабрика ищет в /custom/modules/moduleName/ файл contoller.php, потом в modules/moduleName/, если не там не там файла нет, то создает екземпляр из includes/MVC/Controller/SugarController.php.


SugarController
Два способа присоединить Вью на Екшин:
1) в классе методом action_actionname()
2) через метаданные, файл action_view_map.php, который может переоперделяться в 3-х выше описанных местах.

Перед тем как вызвать action_actionname(), котроллер вызывает pre_actionname(), а после вызова -- post_actionname().

SugarView
Содержит поле $options.
Вот как можно видоизменять вью:
$options['show_title'] = true/false
$options['show_javascript'] = true/false

EntryPoint
Не всегда нужен механизм MVC в обоработке запроса.

SugarBean
Это класс представляющий модель, он отображает таблицу в базе данных. В нем есть медоды для реализации CRUID.
Этот обьект наследуют шаблонные, которые можно использовать для своих обьетов. Они находтся /includes/SugarObjects/templates.
Но четкий вид бину придает файл vardefs.php, которые определяет на какой таблице он основан, какие есть в нем поля и как с ними работать, при этом эти поля не обязательно должны присутсвовать в таблице -- они могут формироваться с нескольких существующих('source' => 'non-db'), или же храниться в другом модуле/таблице, и их нужно получить выборкой не из своей таблицы:

$dictionary['Applicants']['fields']['position_id'] = array(
'name' => 'position_id',
'vname' => 'LBL_POSITION_ID',
'type' => 'id',
'isnull' => 'true',
'reportable' => false,
'massupdate' => false,
'duplicate_merge'=> 'disabled',
'comment' => 'ID field of the position in the Positions module'
);
$dictionary['Applicants']['fields']['position_name'] = array(
'name' => 'position_name',
'rname' => 'name',
'id_name' => 'position_id',
'vname' => 'LBL_ACCOUNT_NAME',
'type' => 'relate',
'table' => 'positions',
'isnull' => 'true',
'module' => 'Positions',
'dbType' => 'varchar',
'len' => '255',
'source' => 'non-db',
'unified_search' => false,
'comment' => 'Name field of the position in the Positions module'
);

indexes
Так мы задаем индексы для таблиц:

$dictionary['Applicants']['indices'][] = array(
'name' =>'applicantspk',
'type' =>'primary',
'fields'=>array('id')
);
$dictionary['Applicants']['indices'][] = array(
'name' =>'idx_applicants_name',
'type' =>'index',
'fields'=>array('last_name','first_name'))
);
$dictionary['Applicants']['indices'][] = array(
'name' =>'idx_applicants_name_unique',
'type' =>'unique',
'fields'=>array('last_name','first_name','position_id'))
);


relationships
С помошью этого массива мы определяем с какими модулями/таблицами связан наш бин. Тут оперереляются поле, модуль, таблица с левой стороны отношения и тоже самое с правой стороны отношения. Также указывается это отношение один-ко-многими или многие-ко-многим. Можно также указать так называемую гибкую связь -- это когда правая сторона может быть связана через свой внейшний ключ не только с нашим модулем, а и с каким-то другим:

$dictionary['Applicants']['relationships']['applicants_modified_user' ] = array (
'lhs_module' => 'Users',
'lhs_table' => 'users',
'lhs_key' => 'id',
'rhs_module' => 'Applicants',
'rhs_table' => 'applicants',
'rhs_key' => 'modified_user_id',
'relationship_type' => 'one-to-many',
);
$dictionary['Applicants']['relationships']['applicants_notes'] = array (
'lhs_module' => 'Applicants',
'lhs_table' => 'applicants',
'lhs_key' => 'id',
'rhs_module' => 'Notes',
'rhs_table' => 'notes',
'rhs_key' => 'parent_id',
'relationship_type' => 'one-to-many',
'relationship_role_column' => 'parent_type',
'relationship_role_column_value' => 'Applicants',);

Это означает что ноуты могут быть прикреплены не только к юзерам, а также коментировать другие модули