Framework Design
От: Михаил Чащин Норвегия  
Дата: 25.11.03 16:18
Оценка: 1828 (47)
Статья:
Framework Design
Автор(ы): Михаил Чащин
Дата: 12.06.2004
Что такое framework? Кто их пишет и кто использует? Что нужно знать и уметь, чтобы написать framework? В данной статье вы найдёте ответы на эти и другие вопросы. Рассматриваются также особенности проектирования и реализации framework на примере графической системы.


Авторы:
Михаил Чащин

Аннотация:
Что такое framework? Кто их пишет и кто использует? Что нужно знать и уметь, чтобы написать framework? В данной статье вы найдёте ответы на эти и другие вопросы. Рассматриваются также особенности проектирования и реализации framework на примере графической системы.
Re: Framework Design
От: _vovin http://www.pragmatic-architect.com
Дата: 23.06.04 09:02
Оценка: 10 (1)
Здравствуйте, Михаил Чащин, Вы писали:

МЧ>Статья:



МЧ>Авторы:

МЧ> Михаил Чащин

МЧ>Аннотация:

МЧ>Что такое framework? Кто их пишет и кто использует? Что нужно знать и уметь, чтобы написать framework? В данной статье вы найдёте ответы на эти и другие вопросы. Рассматриваются также особенности проектирования и реализации framework на примере графической системы.

Для начала – как бы мы не пытались мы никогда не сможем добиться абсолютно идентичной функциональности приложения в Windows и Web. Наипростейшим примером может служить вывод сообщения пользователю. В Windows вы будете писать что-то вроде:
C# code

MessageBox.Show("Hello");


Строго говоря такая проблема успешно разрашается. Но только в языках, поддерживающих Continuation-Passing Style. Более того, существует ряд framework-ов с поддержкой подобной линейной структуры для web applications.

Наиболее успешно развивающимся из них является Seaside:
http://www.beta4.com/seaside2/

Там можно делать что-то подобное:
| user value1 value2 |
[user isNil]
  whileTrue: [user := self call: LoginPage new].
value1 := self call: WizardPage1 new.
value2 := self call: WizardPage2 new.


В данном примере вызывается страничка login, покуда не будет введено корректное имя пользователя. Потом показываются две страницы, на каждой из которых вводится одно значение.
Естественно, возможно и более сложные схемы с многими полями и событиями по нажатию кнопок.

Здесь можно посмотреть как просто реализуется калькулятор:
http://homepage.mac.com/svc/ADayAtTheBeach/

--

Владимир.
Re[2]: Framework Design
От: Mishka Норвегия  
Дата: 23.06.04 09:13
Оценка:
Здравствуйте, _vovin,

_>Строго говоря такая проблема успешно разрашается. Но только в языках, поддерживающих Continuation-Passing Style. Более того, существует ряд framework-ов с поддержкой подобной линейной структуры для web applications.


Я думал над этой проблемой и вот к чему пришёл: для С++, Java и C# эту задачу решить проблематично, но можно. Для этого логику представления нужно запускать в отдельном потоке. В момент вызова ShowMessage поток останавливается и главный поток возвращает страницу клиенту. Когда клиент закроет MessageBox, то форма сабмитится обратно на сервер чтобы продолжить выполнение логики. Но, как легко можно заметить, этот метод крайне не эффективен, поскольку двойной поход на сервер только для того, чтобы показать сообщение — это дорогое удовольствие.
Re: Framework Design
От: Andy_MAN Россия  
Дата: 23.06.04 10:27
Оценка:

Поскольку я не смог найти аналога слова framework в русском языке, который абсолютно точно передавал бы смысловую нагрузку этого термина, я предпочёл использовать в статье непереведённый вариант. Это, на мой взгляд, более приемлемо, нежели использование слова «каркас», по причине того, что разработчики, свободно читающие техническую литературу на английском языке (а таких, я думаю, большинство), могут испытывать трудности с восприятием этого русского варианта в контексте данной статьи.


Мне кажется термин инфраструктура подходит отлично. Я бы перевел так.
Re[2]: Framework Design
От: Mishka Норвегия  
Дата: 23.06.04 10:40
Оценка:
Здравствуйте, Andy_MAN, Вы писали:

A_M>Мне кажется термин инфраструктура подходит отлично. Я бы перевел так.


Это немного разные вещи, хотя опять же вопрос терминологии.

Фреймворк — это язык программирования + API + код, используемый прикладными программистами. Инфраструктура — это набор приожений, которые используют программисты, например, VSS/CVS, Visual Studio/Eclipse. Есть ещё одна составляющая, необходимая для разработки продукта — процесс. Например, XP или RUP. То бишь можно сказать, что для разработки продукта необходимо наличие Фреймворка, Инфраструктуры и Процесса. Если хотя бы одна из составляющих не развита, то и продукт будет не высшего качества.
Я планирую статью написать по этому поводу... чуть позднее
Re[3]: Framework Design
От: _vovin http://www.pragmatic-architect.com
Дата: 23.06.04 10:52
Оценка:
Здравствуйте, Mishka, Вы писали:

M>Здравствуйте, _vovin,


_>>Строго говоря такая проблема успешно разрашается. Но только в языках, поддерживающих Continuation-Passing Style. Более того, существует ряд framework-ов с поддержкой подобной линейной структуры для web applications.


M>Я думал над этой проблемой и вот к чему пришёл: для С++, Java и C# эту задачу решить проблематично, но можно. Для этого логику представления нужно запускать в отдельном потоке. В момент вызова ShowMessage поток останавливается и главный поток возвращает страницу клиенту. Когда клиент закроет MessageBox, то форма сабмитится обратно на сервер чтобы продолжить выполнение логики. Но, как легко можно заметить, этот метод крайне не эффективен, поскольку двойной поход на сервер только для того, чтобы показать сообщение — это дорогое удовольствие.


Есть еще вариант с использованием Fibers. Он одно время обсуждался создателями CLR и C#.

В Java Cacoon framework эта проблема решена вынесением навигационного кода в JavaScript, где "продолжения" уже реализуются не сложно.
Под Unreal Engine был написан свой интерпретируемый Unreal C++ с такими возможностями от рождения.

Во многих сходных случаях проблема решалась таким же образом — ядро писалось на "низкоуровневом" языке (C++, Java), а основная логика реализовывалась на более гибком...

--

Владимир.
Re[3]: Framework Design
От: Andy_MAN Россия  
Дата: 23.06.04 10:55
Оценка:
M>Я планирую статью написать по этому поводу... чуть позднее

Было бы интересно. Будем ждать.

Как я понимаю — Framework + Environment + Process. Дело в том, что англоязычные термины переводить НАДО. Просто не надо бояться немного отступить от смысла и изобрести новый термин. Если сейчас назвать framework инфраструктурой, то потом этот словечко, без сомнения, приживется. А вот Framework IMHO в русском тексте не смотрится. А статью я сегодня прочитаю. Спасибо за то, что делитесь опытом. Удачи.
Re: Framework Design
От: kiamor  
Дата: 23.06.04 13:46
Оценка:
предпоследний абзац грамматическая ошибка:

"...и создание framework позволяет нe только навести эту чистоту, но и поддерживать её".
Re: Framework Design
От: Andy_MAN Россия  
Дата: 24.06.04 06:08
Оценка:
Здравствуйте, Михаил.

Скажите пожалуйста, Михаил, каким образом в вашей среде визуального проектирования форм поддерживается объект Logic? Другими словами, каким образом проектировщик (прикладной программист) программирует поведение формы? Ведь для того, чтобы поддерживать заявленную независимость от языка нужно реализовывать свой псевдокод, который при генерации класса формы нужно транслировать в соответствующий язык. Или многоязыковая поддержка отсутствует в вашем редакторе? Спасибо.
Re[2]: Framework Design
От: Mishka Норвегия  
Дата: 24.06.04 08:46
Оценка:
Здравствуйте, Andy_MAN, Вы писали:

A_M>Скажите пожалуйста, Михаил, каким образом в вашей среде визуального проектирования форм поддерживается объект Logic? Другими словами, каким образом проектировщик (прикладной программист) программирует поведение формы? Ведь для того, чтобы поддерживать заявленную независимость от языка нужно реализовывать свой псевдокод, который при генерации класса формы нужно транслировать в соответствующий язык. Или многоязыковая поддержка отсутствует в вашем редакторе? Спасибо.


Код логики представления пишется прикладным программистом на C#, Java или C++. Но это своего рода промежуточный вариант. Если развивать инфраструктуру дальше, то можно создать некий скриптовый язык, который будет достаточно прост в силу простоты API framework-а. Затем если, например, программа пишется под .NET, будет необходим компилятор переводящий код в C#.
С другой стороны очень многая функциональность может быть вынесена из логики представления. Например, код для binding-а данных к контролам может быть сгенерирован как часть описания формы. Валидация простых правил может быть помещена непосредственно в контролы, и многое другое.
Тут главное замечать паттерны и пытаться описать их на неком языке высокого уровня, чтобы потом просто генерировать код.

P.S. Для полноты картины хочу заметить, что логика представления не должна взаимодействовать с БД напрямую. Более того она также не должна взаимодействовать с объектами домейна напрямую (domain или business objects). Необходим дополнительный слой, который ограничит доступный для прикладного программиста API до минимума. Но об этом я как-нибудь в другой раз напишу Что-то вроде "Framework Design 2: 7-tier architecture"
Re[3]: Framework Design
От: Андрей Майоров Россия http://blogs.byte-force.com/xor
Дата: 24.06.04 09:14
Оценка: 2 (1) -1
Здравствуйте, Mishka, Вы писали:

A_M>>Мне кажется термин инфраструктура подходит отлично. Я бы перевел так.

M>Это немного разные вещи, хотя опять же вопрос терминологии.

Тут, ИМХО, вопрос не терминологии, а лени. Когдя я читал статью, глаз совершенно не спотыкался о framework'и. Но вот если бы я ее писал, то проклял бы все на свете, переключаясь с русского на английский и обратно. Так что лень — один из двигателей движения за чистоту русского языка.
... << RSDN@Home 1.1.3 stable >>
WBR,
XOR // BYTE-force
Re: Framework Design
От: Андрей Майоров Россия http://blogs.byte-force.com/xor
Дата: 24.06.04 09:14
Оценка:
Здравствуйте, Михаил Чащин, Вы писали:

МЧ>Что такое framework? Кто их пишет и кто использует? Что нужно знать и уметь, чтобы написать framework? В данной статье вы найдёте ответы на эти и другие вопросы. Рассматриваются также особенности проектирования и реализации framework на примере графической системы.


Я все ожидал, что к концу статьи будет подтверждение тезиса, что фрейворки писать не нужно, но так и не дождался. Видимо, пока писал настроение поменялось.
... << RSDN@Home 1.1.3 stable >>
WBR,
XOR // BYTE-force
Re[2]: Framework Design
От: Mishka Норвегия  
Дата: 24.06.04 09:26
Оценка:
Здравствуйте, Андрей Майоров, Вы писали:

АМ> Я все ожидал, что к концу статьи будет подтверждение тезиса, что фрейворки писать не нужно, но так и не дождался. Видимо, пока писал настроение поменялось.


Да нет. Писать их надо, но опасно. Я ж вроде упоминал, что написание framework — это риск. Риск не для архитектора или разработчика, а для project manager-ов.
Re[3]: Framework Design
От: Andy_MAN Россия  
Дата: 25.06.04 04:48
Оценка:
Здравствуйте, Михаил, Вы писали:

M>Код логики представления пишется прикладным программистом на C#, Java или C++. Но это своего рода промежуточный вариант. Если развивать инфраструктуру дальше, то можно создать некий скриптовый язык, который будет достаточно прост в силу простоты API framework-а. Затем если, например, программа пишется под .NET, будет необходим компилятор переводящий код в C#.


Лучше всего подошло бы что-нибудь вроде VBA.NET.

M>С другой стороны очень многая функциональность может быть вынесена из логики представления. Например, код для binding-а данных к контролам может быть сгенерирован как часть описания формы. Валидация простых правил может быть помещена непосредственно в контролы, и многое другое.

M>Тут главное замечать паттерны и пытаться описать их на неком языке высокого уровня, чтобы потом просто генерировать код.

Совершенно верно. У меня есть опыт разработки подобной инструментальной среды на Delphi, в которой очень часто можно было найти компоненты с именем вроде TPVCEditableDBGridAndNavigatorWithTreeView, которые прикладной программист (с нашей точки зрения это были уже конечные пользователи) мог поместить на форму и, не написав ни строчки кода, привнести в приложение достаточно богатую функциональность. Но все равно без подключения VBScript в качестве внутреннего скриптового языка не обошлось.
Re[2]: Framework Design
От: achmed Удмуртия https://www.linkedin.com/in/nail-achmedzhanov-9907188/
Дата: 25.06.04 06:33
Оценка:
Здравствуйте, _vovin, Вы писали:

_>Строго говоря такая проблема успешно разрашается. Но только в языках, поддерживающих Continuation-Passing Style. Более того, существует ряд framework-ов с поддержкой подобной линейной структуры для web applications.


что такое Continuation-Passing Style ?
Re: Framework Design
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 06.08.04 08:44
Оценка:
Добрый день, Михаил.
Спасибо за статью.

Вопрос по несущественным техническим деталям.

Отобрали у программистов создание control-ов напрямую и всучили им обязанность создавать фабрику.


Каким образом эту возможность у них отобрали? Что мешает мне, как прикладному программисту, по-прежнему написать

Button b = new WindowsButton(...);
b.Enabled = false;


Т.е. что имеется в виду под запретом? Чисто языковые средства (какие?) или архитектурные особенности (какие?)?. Большое спасибо.
Re[2]: Framework Design
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 06.08.04 08:47
Оценка:
Вдогонку:

public class WindowsFactory // : AbstractFactory

То, что закомментированная часть отсутствует в твоем коде — это просто опечатка или я чего-то не понял?
Re[2]: Framework Design
От: Mishka Норвегия  
Дата: 06.08.04 09:12
Оценка: 1 (1)
Здравствуйте, Alxndr, Вы писали:

A>
A>Button b = new WindowsButton(...);
A>b.Enabled = false;
A>


Если пишешь под .NET, то помещай интерфейс и реализацию фреймворка в разные сборки, компилируй их и давай dll прикладным программистам, при этом документируя только интерфейс. Если для каждой формы будет отдельная dll, то эта dll должна зависеть только от интерфейса фреймворка. Не знаю, можно ли сделать так, чтобы сборку нельзя было подключить как reference к другой сборке (надо покопать security).

Да, кстати, вот кнопку-то ты создал, а ведь её ещё надо на форму добавить, а форма должна быть WindowsForm, а ссылка на неё запрятана глубоко. Можно эту ссылку вообще сделать private и в коде формы вместо form.AddControl, делать invoke.

Но, как говориться, если очень захотеть, то можно до всего докопаться, особенно если вооружиться reflection
Re[3]: Framework Design
От: Mishka Норвегия  
Дата: 06.08.04 09:14
Оценка:
Здравствуйте, Alxndr, Вы писали:

A>Вдогонку:


A>
A>public class WindowsFactory // : AbstractFactory
A>

A>То, что закомментированная часть отсутствует в твоем коде — это просто опечатка или я чего-то не понял?

Опечатка.
Re[3]: Framework Design
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 06.08.04 09:28
Оценка:
Здравствуйте, Mishka, Вы писали:

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


A>>
A>>Button b = new WindowsButton(...);
A>>b.Enabled = false;
A>>


M>Если пишешь под .NET, то помещай интерфейс и реализацию фреймворка в разные сборки, компилируй их и давай dll прикладным программистам, при этом документируя только интерфейс. Если для каждой формы будет отдельная dll, то эта dll должна зависеть только от интерфейса фреймворка.


И? Не мог бы ты чуть подробнее пояснить свою мысль?
Кстати, а не спасет ли нас обычный internal конструктор в этом случае?

Не было ли лучше в данном конкретном случае вообще воспользоваться "виртуальным конструтором"?

public class Button
{
    public virtual Button Create() { return new Button(...); }
    protected Button(...) { ... }
}

public class WinButton
{
    public override Button Create() { return new WinButton(...); }
}
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.