Аннотация:
Что такое framework? Кто их пишет и кто использует? Что нужно знать и уметь, чтобы написать framework? В данной статье вы найдёте ответы на эти и другие вопросы. Рассматриваются также особенности проектирования и реализации framework на примере графической системы.
МЧ>Авторы: МЧ> Михаил Чащин
МЧ>Аннотация: МЧ>Что такое framework? Кто их пишет и кто использует? Что нужно знать и уметь, чтобы написать framework? В данной статье вы найдёте ответы на эти и другие вопросы. Рассматриваются также особенности проектирования и реализации framework на примере графической системы.
Для начала – как бы мы не пытались мы никогда не сможем добиться абсолютно идентичной функциональности приложения в Windows и Web. Наипростейшим примером может служить вывод сообщения пользователю. В Windows вы будете писать что-то вроде:
C# code
MessageBox.Show("Hello");
Строго говоря такая проблема успешно разрашается. Но только в языках, поддерживающих Continuation-Passing Style. Более того, существует ряд framework-ов с поддержкой подобной линейной структуры для web applications.
В данном примере вызывается страничка login, покуда не будет введено корректное имя пользователя. Потом показываются две страницы, на каждой из которых вводится одно значение.
Естественно, возможно и более сложные схемы с многими полями и событиями по нажатию кнопок.
Здравствуйте, _vovin,
_>Строго говоря такая проблема успешно разрашается. Но только в языках, поддерживающих Continuation-Passing Style. Более того, существует ряд framework-ов с поддержкой подобной линейной структуры для web applications.
Я думал над этой проблемой и вот к чему пришёл: для С++, Java и C# эту задачу решить проблематично, но можно. Для этого логику представления нужно запускать в отдельном потоке. В момент вызова ShowMessage поток останавливается и главный поток возвращает страницу клиенту. Когда клиент закроет MessageBox, то форма сабмитится обратно на сервер чтобы продолжить выполнение логики. Но, как легко можно заметить, этот метод крайне не эффективен, поскольку двойной поход на сервер только для того, чтобы показать сообщение — это дорогое удовольствие.
Поскольку я не смог найти аналога слова framework в русском языке, который абсолютно точно передавал бы смысловую нагрузку этого термина, я предпочёл использовать в статье непереведённый вариант. Это, на мой взгляд, более приемлемо, нежели использование слова «каркас», по причине того, что разработчики, свободно читающие техническую литературу на английском языке (а таких, я думаю, большинство), могут испытывать трудности с восприятием этого русского варианта в контексте данной статьи.
Мне кажется термин инфраструктура подходит отлично. Я бы перевел так.
Здравствуйте, Andy_MAN, Вы писали:
A_M>Мне кажется термин инфраструктура подходит отлично. Я бы перевел так.
Это немного разные вещи, хотя опять же вопрос терминологии.
Фреймворк — это язык программирования + API + код, используемый прикладными программистами. Инфраструктура — это набор приожений, которые используют программисты, например, VSS/CVS, Visual Studio/Eclipse. Есть ещё одна составляющая, необходимая для разработки продукта — процесс. Например, XP или RUP. То бишь можно сказать, что для разработки продукта необходимо наличие Фреймворка, Инфраструктуры и Процесса. Если хотя бы одна из составляющих не развита, то и продукт будет не высшего качества.
Я планирую статью написать по этому поводу... чуть позднее
Здравствуйте, 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), а основная логика реализовывалась на более гибком...
M>Я планирую статью написать по этому поводу... чуть позднее
Было бы интересно. Будем ждать.
Как я понимаю — Framework + Environment + Process. Дело в том, что англоязычные термины переводить НАДО. Просто не надо бояться немного отступить от смысла и изобрести новый термин. Если сейчас назвать framework инфраструктурой, то потом этот словечко, без сомнения, приживется. А вот Framework IMHO в русском тексте не смотрится. А статью я сегодня прочитаю. Спасибо за то, что делитесь опытом. Удачи.
Скажите пожалуйста, Михаил, каким образом в вашей среде визуального проектирования форм поддерживается объект Logic? Другими словами, каким образом проектировщик (прикладной программист) программирует поведение формы? Ведь для того, чтобы поддерживать заявленную независимость от языка нужно реализовывать свой псевдокод, который при генерации класса формы нужно транслировать в соответствующий язык. Или многоязыковая поддержка отсутствует в вашем редакторе? Спасибо.
Здравствуйте, 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"
Здравствуйте, Mishka, Вы писали:
A_M>>Мне кажется термин инфраструктура подходит отлично. Я бы перевел так. M>Это немного разные вещи, хотя опять же вопрос терминологии.
Тут, ИМХО, вопрос не терминологии, а лени. Когдя я читал статью, глаз совершенно не спотыкался о framework'и. Но вот если бы я ее писал, то проклял бы все на свете, переключаясь с русского на английский и обратно. Так что лень — один из двигателей движения за чистоту русского языка.
Здравствуйте, Михаил Чащин, Вы писали:
МЧ>Что такое framework? Кто их пишет и кто использует? Что нужно знать и уметь, чтобы написать framework? В данной статье вы найдёте ответы на эти и другие вопросы. Рассматриваются также особенности проектирования и реализации framework на примере графической системы.
Я все ожидал, что к концу статьи будет подтверждение тезиса, что фрейворки писать не нужно, но так и не дождался. Видимо, пока писал настроение поменялось.
Здравствуйте, Андрей Майоров, Вы писали:
АМ> Я все ожидал, что к концу статьи будет подтверждение тезиса, что фрейворки писать не нужно, но так и не дождался. Видимо, пока писал настроение поменялось.
Да нет. Писать их надо, но опасно. Я ж вроде упоминал, что написание framework — это риск. Риск не для архитектора или разработчика, а для project manager-ов.
Здравствуйте, Михаил, Вы писали:
M>Код логики представления пишется прикладным программистом на C#, Java или C++. Но это своего рода промежуточный вариант. Если развивать инфраструктуру дальше, то можно создать некий скриптовый язык, который будет достаточно прост в силу простоты API framework-а. Затем если, например, программа пишется под .NET, будет необходим компилятор переводящий код в C#.
Лучше всего подошло бы что-нибудь вроде VBA.NET.
M>С другой стороны очень многая функциональность может быть вынесена из логики представления. Например, код для binding-а данных к контролам может быть сгенерирован как часть описания формы. Валидация простых правил может быть помещена непосредственно в контролы, и многое другое. M>Тут главное замечать паттерны и пытаться описать их на неком языке высокого уровня, чтобы потом просто генерировать код.
Совершенно верно. У меня есть опыт разработки подобной инструментальной среды на Delphi, в которой очень часто можно было найти компоненты с именем вроде TPVCEditableDBGridAndNavigatorWithTreeView, которые прикладной программист (с нашей точки зрения это были уже конечные пользователи) мог поместить на форму и, не написав ни строчки кода, привнести в приложение достаточно богатую функциональность. Но все равно без подключения VBScript в качестве внутреннего скриптового языка не обошлось.
Здравствуйте, _vovin, Вы писали:
_>Строго говоря такая проблема успешно разрашается. Но только в языках, поддерживающих Continuation-Passing Style. Более того, существует ряд framework-ов с поддержкой подобной линейной структуры для web applications.
A>Button b = new WindowsButton(...);
A>b.Enabled = false;
A>
Если пишешь под .NET, то помещай интерфейс и реализацию фреймворка в разные сборки, компилируй их и давай dll прикладным программистам, при этом документируя только интерфейс. Если для каждой формы будет отдельная dll, то эта dll должна зависеть только от интерфейса фреймворка. Не знаю, можно ли сделать так, чтобы сборку нельзя было подключить как reference к другой сборке (надо покопать security).
Да, кстати, вот кнопку-то ты создал, а ведь её ещё надо на форму добавить, а форма должна быть WindowsForm, а ссылка на неё запрятана глубоко. Можно эту ссылку вообще сделать private и в коде формы вместо form.AddControl, делать invoke.
Но, как говориться, если очень захотеть, то можно до всего докопаться, особенно если вооружиться reflection
Здравствуйте, 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(...); }
}