>>"Самое главное - это расположить инклуды с моделью и представлением до инклуда с контроллером"
 
А может проще написать в начале что-то типа:
CLASS: <имя> DEFINITION DEFERRED,
       <имя> DEFINITION DEFERRED,
       <имя> DEFINITION DEFERRED.
 
И тогда будет все равно как оно там дальше в инклудах находится.

Необходимости нет. По-хорошему во view должна быть ссылка на модель и view должна сама брать данные из модели. А из модели уж как угодно можно данные выдавать или как атрибут или через метод (зависит от того насколько надо абстрагироваться). Тогда и контроллер не будет зависеть от структуры модели. В контроллере должна быть только настройка связи между view и model.
 
Не совсем правильно, потому что такая передача нарушает инкапсуляцию внутренностей объекта модель, контроллер "знает" как устроена модель, хотя, по идее, ему должно быть всё равно, что внутри модели. Если конечно придерживаться концепции пассивной модели, то и передача через контроллер выглядит нормальной, так как вся бизнес логика всё равно будет сосредоточена в контроллере. А если делать контроллер по всем правилам, то в нём должна быть только логика управления связями между остальными объектами и маршрутизация сообщений в их обработчики. Для простого ALV отчета, это правда уже перебор.

Цифры получаются не после внедрения системы, а по итогам всего проекта (система, методология, служба, нормализация объектов НСИ).
Поделитесь опытом, какой профит по-вашему мнению от проекта НСИ, какими показателями его можно оценить?

Who "simply the best"?

Знаю, практически со всеми основными продуктами, представленными на рынке, работал.

По моему опыту, все эти цифры - высосаны из пальца. Нормальный бизнес сразу спросит - а как эти цифры получены? А где тут влияние данных? А может проще вычистить данные в текущей системе?

Ну тут бизнесу придется выбирать, либо мы имеем более-менее качественные данные, либо не заморачиваемся над фасетами вообще.
По факту, классификацию на таком уровне поддерживать несложно, ограничивая глубину описания на второстепенных классах.
Ну а то, что классификатор будет развиваться, мне кажется, это самоочевидная вещь.

Есть еще решения и других вендоров...

Опыт проектов + некоторые открытые данные.

Согласен, что нормализация начинается с методологии,но также необходимо понимание Бизнеса, что он хочет и для чего.
Параметрическая классификация - это Вы имеете ввиду свойства и значения ТМЦ? Тогда здесь хочу уточнить фразой из статьи:
"Невозможно поддерживать и развивать фасетную классификацию всего справочника ТМЦ, т.к. потребности бизнеса всегда будут расти и изменяться, следовательно, должен будет меняться и классификатор, и все позиции в нем."

Поиск аналогов как раз в MDM проще реализовать, чем в MDG.

На основе чего получены данные цифры?

НОрмализация ОЗМ начинается с грамотного методолога и выявления типовых проблем. Почему 2 года справочник чистили - вообще не понятно, работы для "маленького заводика" - максимум на полгода, за год весь Газпром можно вычистить, или корпорацию сопоставимого масштаба (был такой опыт).
А проблемы основные -
1. Дублирующиеся записи
2. Неполные записи
3. Некорректные записи
4. Противоречивые записи
5. "Абсурдные" записи
Хорошо помогает параметрическая классификация с прошитой в интерфейсе  обязательностью, а также хорошая трудовая дисциплина.

В данном случае передача таблицы в display скорее необходимость. Т.к. в конструктор передать changing параметр невозможно.
 
Вывод не только таблицы будет показан в дальнейшем.
 
"Не совсем правильно с точки зрения ООП" - хотелось бы немного аргументации...

1. Иван, разве обновление данных не должно происходить через контроллер (рис.1)?
2. Не описана обработка действий пользователя VIEW. Хочется видеть хотя бы самый простой пример.

Передавать таблицу в display не совсем правильно с точки зрения ООП, вроде. Например, появиться требование вывести кроме таблицы, ещё какую-нибудь заголовочную часть. Потребуется вносить изменения в контроллер, хотя изменилась только структура данных и её отображение, а управление осталось прежним.

у Вас в разработке по сути 2 view, независимых друг от друга:
1) это селекционный экран отчета
2) и экран ALV на базе класса cl_salv_table
и эти два view контролируются разными controller (1 - создается стандартно за кадром; 2 - создался Вами).
 
кроме того, Вы говорите
"данный шаблон отлично подходит (масштабируется) для отчетов с большим количеством всевозможных enjoysap control'ами с реализацией их взаимодействия.", а при этом используете упрощенный класс cl_salv_table.
почему?