Форум Сообщества Аналитиков

×


Помогите найти патерн...(Прочитано 8822 раз)
Помогите найти патерн... : 27 Июня 2007, 13:50:42
Ситуация такая....
Я, правда, сам пока плохо себе предсятавляю как это должно выглядеть (пока на стадии обдумывания), но попытаюсь максимально емко выразить проблему.
Я плохо разбираюсь в проектировании, и только начал с этим разбираться.
Как я понимаю, есть уже ряд задач которые програмисты решали, и дабы каждый не создавал велосипед, решения (патерны) определенно описали и назвали.
Передо мной стоит задача, которую 100% уже решали, вот я и подумал, может есть такой патерн....

Грубо говоря :
есть GUI, и движок. мне надо спроектировать прокладку (назовем его Manager) между ними и обеспечить гибкую взаимосвязь.
Например, пользователь через юзер интерфейс просит что-то сделать, Manager создает "сред" и делает.... а в этот момент движек шлет свои ивенты, их надо получать как Manager'у так реагировать на них в UI.

Хотелось бы получить элегантное решение....



Re: Помогите найти патерн... Ответ #1 : 27 Июня 2007, 17:35:52
попробуйте все-таки еще раз сформулировать весь вопрос грамматически точно, а то что-то и запятые и глаголы и общий смысл теряется. Приходится додумывать, а это не правильно



Re: Помогите найти патерн... Ответ #2 : 28 Июня 2007, 00:00:04
Этот паттерн называется "Model-View-Controller"
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Помогите найти патерн... Ответ #3 : 08 Июля 2007, 18:06:30
Этот паттерн называется "Model-View-Controller"
а с этого места по подробнее пожалуйста. Угостите ссылками, желательно русскими.



Re: Помогите найти патерн... Ответ #4 : 09 Июля 2007, 12:43:24
а с этого места по подробнее пожалуйста. Угостите ссылками, желательно русскими.
Насчет ссылок не подскажу. Попробуйте в яндаксе прости поискать или в гугле. Но типичный такой паттерн.
Модель - фактически база данных или диаграмма классов, если примитивно,
Контроллер - нечто, что управляет изменением данных, их поиском, предоставлением и т.п.
Вью - логика отображения.
Берем например аксессное приложение:
1. модель - таблицы, связи, ограничения, некоторые функции тесто связанные с изменением данных (триггеры и хранимые процедуры, которых в аксесс правда нет), запросы.
2. контроллеры - это могут быть запросы, макросы, модули
3. Вью - собственно формы, отчеты



Re: Помогите найти патерн... Ответ #5 : 09 Июля 2007, 13:00:02
а с этого места по подробнее пожалуйста. Угостите ссылками, желательно русскими.
можешь посмотреть Фаулера "Архитектура корпоративных программных приложений"
Скачать книжку можно здесь
http://www.natahaus.ru/2006/09/07/arkhitektura_korporativnykh_programmnykh_prilozhenijj.html
и тут можно почитать
http://www.natahaus.ru/2006/01/23/primenenie_shablonov_Java.html

Это ссылки на книжки. А вообще по шаблонам много всего в инете можно найти.
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Re: Помогите найти патерн... Ответ #6 : 09 Июля 2007, 15:35:06
можешь посмотреть Фаулера "Архитектура корпоративных программных приложений"
Скачать книжку можно здесь
http://www.natahaus.ru/2006/09/07/arkhitektura_korporativnykh_programmnykh_prilozhenijj.html
и тут можно почитать
http://www.natahaus.ru/2006/01/23/primenenie_shablonov_Java.html

Это ссылки на книжки. А вообще по шаблонам много всего в инете можно найти.
за ссылки, спасибо. А вот причём здесь шаблоны я не понял :(

Galogen, спасибо.



Re: Помогите найти патерн... Ответ #7 : 09 Июля 2007, 16:12:56
А вот причём здесь шаблоны я не понял :(
А притом что первая книга по английски называется Patterns of Enterprise Application Architecture и там более 400 страниц описания различных шаблонов с примерами на языке Java и C#
Одним из них является шаблон MVC
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Re: Помогите найти патерн... Ответ #8 : 09 Июля 2007, 17:16:45
Страница 348 русского перевода:
Цитировать
Принцип действия
Типовое решение модель-представление—контроллер подразумевает выделение трех отдельных ролей. Модель— это объект, предоставляющий некоторую информацию о домене. У модели нет визуального интерфейса, она содержит в себе все данные и поведе¬ние, не связанные с пользовательским интерфейсом. В объектно-ориентированном кон¬тексте наиболее "чистой" формой модели является объект модели предметной области (Domain Model, 140). В качестве модели можно рассматривать и сценарий транзакции (Transaction Script, 133), если он не содержит в себе никакой логики, связанной с пользо¬вательским интерфейсом. Подобное определение не очень расширяет понятие модели, однако полностью соответствует распределению ролей в рассматриваемом типовом ре¬шении.
Представление отображает содержимое модели средствами графического интерфейса. Таким образом, если наша модель — это объект покупателя, соответствующее представ¬ление может быть фреймом с кучей элементов управления или HTML-страницей, запол¬ненной информацией о покупателе. Функции представления заключаются только в ото¬бражении информации на экране. Все изменения информации обрабатываются третьим "участником" нашей системы — контроллером. Контроллер получает входные данные от пользователя, выполняет операции над моделью и указывает представлению на необхо¬димость соответствующего обновления. В этом плане графический интерфейс можно рассматривать как совокупность представления и контроллера.
Говоря о типовом решении модель—представление—контроллер, нельзя не подчеркнуть два принципиальных типа разделения: отделение представления от модели и отделение контроллера от представления.
Отделение представления от модели — это один из фундаментальных принципов про¬ектирования программного обеспечения. Наличие подобного разделения весьма важно по ряду причин.
•   Представление и модель относятся к совершенно разным сферам программирова¬
ния. Разрабатывая представление, вы думаете о механизмах пользовательского ин¬
терфейса и о том, как сделать интерфейс приложения максимально удобным для
пользователя. В свою очередь, при работе с моделью ваше внимание сосредоточе¬
но на бизнес-политиках и, возможно, на взаимодействии с базой данных. Очевид¬
но, при разработке модели и представления применяются разные (совершенно
разные!) библиотеки. Кроме того, большинство разработчиков специализируются
только в одной из этих областей.
•   Пользователи хотят, чтобы, в зависимости от ситуации, одна и та же информация
могла быть отображена разными способами. Отделение представления от модели
позволяет разработать для одного и того же кода модели несколько представлений,
а точнее, несколько абсолютно разных интерфейсов. Наиболее наглядно данный
подход проявляется в том случае, когда одна и та же модель может быть представ¬
лена с помощью толстого клиента, Web-обозревателя, удаленного API или интер¬
фейса командной строки. Даже в пределах одного и того же Web-интерфейса в
разных местах приложения одному и тому же покупателю могут соответствовать
разные страницы.
• Объекты, не имеющие визуального интерфейса, гораздо легче тестировать, чем объекты с интерфейсом. Отделение представления от модели позволяет легко про¬тестировать всю логику домена, не прибегая к таким "ужасным" вещам, как сред¬ства написания сценариев для поддержки графического интерфейса пользователя.
Ключевым моментом в отделении представления от модели является направление зависимостей: представление зависит от модели, но модель не зависит от представления. Программисты, занимающиеся разработкой модели, вообще не должны быть осведомле¬ны о том, какое представление будет использоваться. Это существенно облегчает разра¬ботку модели и одновременно упрощает последующее добавление новых представлений. Кроме того, это означает, что изменение представления не требует изменения модели.
Данный принцип тесно связан с распространенной проблемой. При использовании толстого клиента с множеством диалоговых окон на экране могут одновременно нахо¬диться несколько представлений одной и той же модели. Если пользователь внесет из¬менения в модель посредством одного представления, эти изменения должны быть от¬ражены и во всех остальных представлениях. Чтобы это было возможным при отсутствии двунаправленной зависимости, необходимо реализовать типовое решение наблюдатель (Observer) [20] с использованием метода распространения событий (event propagation) или в виде типового решения слушатель (Listener). В этом случае представление будет выполнять роль "наблюдателя" за моделью: как только модель будет изменена, представ¬ление генерирует соответствующее событие и все остальные представления обновляют свое содержимое.
Отделение контроллера от представления не играет такой важной роли, как предыду¬щий тип разделения. Действительно, по иронии судьбы практически во всех версиях Smalltalk разделение на контроллер и представление не проводилось. Классическим при¬мером необходимости подобного разделения является поддержка редактируемого и не-редактируемого поведения. Этого можно достичь при наличии одного представления и двух контроллеров (для двух вариантов использования), где контроллеры являются стра¬тегиями [20], используемыми представлением. Между тем на практике в большинстве систем каждому представлению соответствует только один контроллер, поэтому разделе¬ние между ними не проводится. О данном решении вспомнили только при появлении Web-интерфейсов, где отделение контроллера от представления оказалось чрезвычайно полезным.
Тот факт, что в большинстве инфраструктур пользовательских интерфейсов не про¬водилось разделение на представление и контроллер, привел к множеству неверных тол¬кований типового решения модель-представление—контроллер. Да, наличие модели и представления очевидно, но где же контроллер? Многие решили, что контроллер нахо¬дится между моделью и представлением, как в контроллере приложения (Application Controller, 397). Данное заблуждение еще более усугубил тот факт, что в обоих названиях фигурирует слово "контроллер". Между тем, несмотря на все положительные качества контроллера приложения, он ничем не похож на контроллер типового решения модель-представление—контроллер.
Описанные принципы — это все, что требуется для понимания данного набора типо¬вых решений. Если же вам захочется еще немного покопаться в типовом решении мо¬дель-представление—контроллер, обратитесь к источнику [33] — там содержится лучшее на данный момент описание этого типового решения.
Назначение
Как уже отмечалось, ценность типового решения модель—представление—контроллер
заключается в наличии двух типов разделения. Отделение представления от модели — один из основополагающих принципов, на котором держится все проектирование про¬граммного обеспечения, и пренебрегать им можно только тогда, когда речь идет о совсем простых системах, в которых модель вообще не имеет какого-либо реального поведения. Как только в приложении появляется невизуализированная логика, разделение стано¬вится крайне необходимым. К сожалению, во многих инфраструктурах пользовательских интерфейсов реализовать подобное разделение довольно сложно, а там, где это неслож¬но, о нем все равно забывают.
Отделение представления от контроллера не так важно, поэтому рекомендую прово¬дить его только в том случае, когда оно действительно нужно. Подобная необходимость практически не возникает в системах с толстыми клиентами, а вот в Web-интерфейсах отделение контроллера весьма полезно. Большинство рассматриваемых здесь типовых решений, предназначенных для проектирования Web-приложений, основаны именно на этом принципе.

А вообще это уже стандарт. Посмотрите RUP как описывает реализацию системного ВИ: как минимум 1 граничный класс (вот вам и view) , который соединяется с 1 как минимум управляющим классом (т.е. контроллером) и наконец, класс-сущность, опять же как минимум 1 (ничто иное как перзистент сущность, т.е. нечто что важно хранить или формировать между вычислениями, хранится может как угодно, но обычно в виде реляционных таблиц)
Применительно к ООП, можно сказать:
классы-сущности не обладают поведением (трудно поведение хранить в реляционной бд), хотя это на самом деле и не так, но для просты можно, т.е. хранят важнейшую информацию от предметной области некоего бизнеса или приложения, например вот это самое сообщение, помеченное как ответ на тему и привязанное к автору, т.е. мне
далее
класс-контроллер, т.е. некий объект, который осуществялет связь интерфейса (в нашем случае вот этого самого редактора сообщений и базы данных в которой это сообщение потом будет сохранено), т.е. когда я нажму кнопочку отправить, ентот самый класс контроллер, а возможно и целая масса этих классов, проверит мое сообщение на профпригодность, допустимость и т.п. Если все окей, пошелет запрос на соединение с БД сервером, выберет БД или сразу нужную таблицу, осуществит запрос на добавление, проверит отклик и выдаст управление на обновление страницы.
Здесь мы видим четоке разделение полномочий и действия принципов ООП: как минимум инкапсуляция, разделение отвественности



Re: Помогите найти патерн... Ответ #9 : 12 Сентября 2007, 11:49:21
Model-View-Controller хорошо описан в статьях на сайте:
http://www.rsdn.ru/





 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19