Здравствуйте, baranovskiyne, Вы писали:

B>Добрый день.
B> Занимаюсь изучением CAB, Smart Client и т.д.
B> У меня возникает вопрос: в паттернах MVC и MVP модель (в CAB — это, я так понял, — WorkItem) и View (SmartPart) — разорваны, т.е. модель не знает о вью и наоборот. Во всех же примерах модель не просто знает о вью — но и сама создает его, а вью зачастую создает экземпляры модели. Либо я неправильно разобрался в терминологии либо одно из двух...
B>В чем тут дело, подскажите плиз.

Привет,

WorkItem в CAB — это контейнер компонентов (компонентами может выступать практически всё начиная от воркспейсов, смартпатов, сервисов и т.д., заканчивая другими воркайтемами, которые являются дочерними к данному). Главная цель контейнеров (в контексте CAB — WorkItem) — это сделать так, чтобы объекты, которые тесно взаимодействуют друг с другом (это могут быть Views, которые отображают информацию, Presenters, которые управляют этими Views, сервисы, которые необходимы для работы этих Presenters и Views) создавались и уничтожались одновременно. Т.е. WorkItem не есть модель.
Моделью в конетксте CAB может выступать States, которые есть у этого WorkItem'а. Но ты так же можешь создать сервис, к которому будешь обращаться за получением и обновлением данных.

Далее, создание.
Что происходит, когда запускается приложение CAB:

— инициализация сервисов CAB
— создание RootWorkItem, который является главным WorkItem'ом приложения
— конструируется Shell — главная форма приложения
— вызывается метод AfterShellCreated() у ShellApplication, в котором можно инициализировать необходимые States, Workspaces, UI Elements и др.
— загружаются модули, прописанные в ProfileCatalog.xml (зависит от реализации)
— для каждого модуля встраивается WorkItem и вызывается метод Load() у класса, производного от ModuleInit

А дальше твой модуль может отображать виды в вокрспейсы, и проводить необходимую инициализацию.

Получается что WorkItem знает о смартпатах, которые ему надо создать, он их создаёт. А SmartPart знает о своём Presenter'е.
Здесь по рекомендации Microsoft следующая зависимость:

— ConcreteView реализует интерфейс IConcreteView
— View знает о своём ConcretePresenter и может создавать его экземпляр
— при создании ConcretePresenter, свойству ConcretePresenter.View устанавливается ConcreteView, который его создал
— в свойство WorkItem у ConcretePresenter инжектится WorkItem, создавший ConcreteView

Т.е. с презентером ты можешь общаться напрямую, а вот презентер ко View стучится через интерфейс. Это существенно облегчает unit-тестирование, потому что вместо реального ConcreteView ты можешь какой-нить фейк впихнуть.

Но это только рекомендации.

Мда.. написал много.
В кратце: WorkItem — не модель. И презентер может общаться с WorkItem напрямую. Так же он может получить необходимые сервисы через ServiceDependency.
Ну и общение между Views лучше проводить через презентеры через Publish/Subscribe.

Надеюсь, всё доступно объяснил