Можно ли преобразовать приложение MFC C ++ для настольного компьютера в веб-приложение?

Question

У меня очень большое приложение, 1,5 миллиона строк C ++, которое в настоящее время основано на MFC с использованием архитектуры Document / View. Приложение включает в себя множество трехмерной векторной графики, электронных таблиц и очень много диалогов и окон. В пределах ограничений DVA это довольно хорошо написано, в том, что в пользовательском интерфейсе нет значительной программной логики, и все, что может быть сделано с использованием пользовательского интерфейса, также может быть выполнено программно с использованием интерфейса автоматизации COM / OLE. 1001 *

По просьбе ряда пользователей я играю с идеей создания интерфейса браузера с программой, где сама программа запускается на сервере. Мысли пока что преобразуют все интерфейсы COM в DCOM и переписывают / переносят интерфейс пользователя на Java. Первоначальные эксперименты показывают, что это будет огромный объем работы.

У кого-нибудь еще есть идеи для более легкой реализации? Кто-нибудь сталкивался с каким-либо рефакторингом или подобными инструментами, специально предназначенными для такого рода порта?

Answer 1

Короткий ответ: это выполнимо, не используйте Java, и это будет значительный объем работы.

Несколько лет назад (примерно во времена IE5) клиент попросил меня ответить на этот вопрос. Данное приложение было хорошо структурированным трехуровневым настольным приложением.

Результатом исследования стало то, что это возможно. Рассматривались следующие варианты: Java и CGI с использованием CORBA или COM / DCOM. Создание апплета Java было рассмотрено, но исключено, поскольку оно не слишком отличалось бы от настольной версии C ++.

В качестве подхода был выбран базовый уровень, который превратился в серверное приложение, расположенное за уровнем cgi. Пользовательский интерфейс был в значительной степени переписан с использованием того, что мы теперь знаем как Ajax, то есть Javascript и HTML. Пользовательский интерфейс был разделен между элементами браузера и элементами сервера.

Я подумал о том, чтобы написать инструмент для преобразования документов, представлений и диалогов и обернуть их в совместимый формат, однако после долгого анализа стало очевидно, что сделать это было нереально, поскольку MFC на самом деле довольно тесно связан с Win32 API и сам. В зависимости от количества диалогов, возможно, стоит написать что-то для их преобразования.

Я обнаружил, что даже в хорошо структурированной системе довольно много кода, который должен был быть в бэкэнде, просочился в интерфейс.

Если бы я сделал то же самое сейчас, есть несколько превосходных библиотек javascript, которые бы помогли, но я бы все же использовал тот же подход, чтобы сделать как можно больше в браузере с использованием Ajax, возможно с чем-то вроде qooxdoo или YUI . Я также, вероятно, хотел бы перевести взгляд на использование XUL и перемещение по крайней мере большинства диалогов в серверную часть.

Единственное, что меня касается в вашем списке требований, - это векторная 3d графика, хотя в этой игрушке JS или JS3D .

Это только краткое резюме, так как я стараюсь не писать диссертацию.

Answer 2

Прежде чем подумать о преобразовании приложения MFC в веб-приложение, я предлагаю вам прочитать « Как избежать невероятной долины пользовательского интерфейса » от Джеффа Этвуда.

Если вы рассматриваете или активно создаете Ajax / RIA-приложения, вам следует рассмотреть Uncanny Valley с дизайном пользовательского интерфейса. Когда вы создаете приложение в стиле «рабочий стол в веб-браузере», вы нарушаете неписаные ожидания пользователей о том, как веб-приложение должно выглядеть и вести себя. Этот выбор может оказать существенное негативное влияние на обучаемость, приятность использования и принятие.

Я не знаю, как выглядит ваше приложение и насколько хорошо оно «переносимо», но, возможно, создание точной копии приложения для Интернета - не лучший выбор.

Answer 3

Проверьте, может ли Wt соответствовать вашим потребностям. Это набор инструментов веб-приложения C ++.

Answer 4

Да, мы сделали это с помощью большого (Borland) C ++ приложения, которое лучше всего можно охарактеризовать как имеющее архитектуру «большого грязного шара».

У вас есть некоторые интересные проблемы впереди, но мы сделали очень «webby» и привлекательный интерфейс (прототип в ASP.NET, но может быть любым, включая Java), который в основном просто запускает события в настольном приложении, запущенном на сервер, а затем отображает полученные графики, таблицы и текст. Мы гибки в том, как отображать что-то вроде графиков - как .PNG, flash-объекты или .SVG в зависимости от браузера

Работает на удивление хорошо, и на реализацию программы ушло всего несколько месяцев, как только мы разобрались с моделью (проблема была в дизайне).

На данный момент мы реализовали только полезный поднабор всего настольного приложения, но по мере продолжения бэкэнд будет более четко отделяться от внешнего интерфейса (и уменьшаться в размере). Если у вас уже есть хорошее разделение между GUI и back-end, то это большое преимущество.

Мы также рассмотрели в основном автоматическое создание веб-интерфейса из приложения, но на этапе проектирования решили, что оно будет слишком похоже на приложение Windows32, работающее в окне браузера ....

Answer 5

Это было несколько лет назад с тех пор, как я поиграл с этим, но однажды я попробовал взять небольшое приложение и скомпилировать его как активный компонент X, который затем можно было бы легко использовать на веб-странице. (Это приложение было основано на форме, созданной с помощью Borland C ++ Builder, поэтому сделать его активным компонентом X довольно тривиально. Я не мог судить, насколько это сложно быть приложением MFC D / V как компонент Active X).

Необходимо было зарегистрировать активный компонент X на компьютере пользователя (также довольно тривиально, но вам приходилось перерегистрировать каждую новую версию компонента - я чувствовал, что заполняю реестр) и в настоящее время Internet Explorer выдает предупреждения с веб-страницами, используя ActiveX так что это потребует от пользователя понижения уровня безопасности в I.E. чтобы не жаловаться.

Answer 6

Это будет значительный объем работы, но вы уже сделали хороший дизайн, так что вы уже на полпути!

Я бы начал с перемещения вашего пользовательского интерфейса MFC в отдельный исполняемый файл и использования его для управления внутренним кодом. Как только вы это сделаете (что должно быть относительно просто, поскольку вы просто перепаковываете существующий код), вы получите гораздо лучшее представление о том, сможет ли он обрабатывать несколько пользователей, подключающихся к одному внутреннему серверу.

Как только вы это исправите, вы сможете увидеть все области, где вам нужно реализовать подключение к бэкэнду, и вы можете начать переписывать пользовательский интерфейс на любом языке или платформе, которые вам нравятся.

Для веб-интерфейса я бы написал код веб-сервера, который взаимодействовал с вашим внутренним сервером. Таким образом, вы получаете намного более простое соединение, и у вас гораздо меньше проблем с безопасностью и связью. Я всегда думаю, что веб-сервер + браузер - это уровень представления в n-уровневом приложении.

Что касается веб-технологий, вы можете использовать flex, activex, silverlight или, возможно, jquery / jsext, чтобы получить богатый контент в браузере.