Использование VCL для Web (Intraweb) в качестве трюка для добавления веб-интерфейса к устаревшему неразмерным (2 уровня) приложение Delphi Win32 имеет смысл?

Question

Моя команда поддерживает огромный клиентский сервер Win32 Delphi приложения. Это клиент / серверное приложение (толстый клиент), который использует компоненты Devart (SDAC) для подключения к SQL Server.

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

Теперь есть запрос веб-интерфейса, у меня есть несколько вариантов, конечно, в этот вопрос я хочу сосредоточиться на VCL для параметра Web (IntraweB).

Идея состоит в том, чтобы использовать общий код (одинаковые файлы PAS) как для приложения клиента / сервера, так и веб-приложения. Я слышал о многих людях, которые перемещали наследие приложений из Delphi для IntraWeb, но здесь я тоже пытаюсь сохранить толстый клиент тоже.

Идея состоит в том, чтобы использовать общий код, может быть с некоторыми директивами компилятора для записи определенного кода:

{$IFDEF CLIENTSERVER}
  {here goes the thick client specific code}
{$ELSE}
  {here goes the Intraweb specific code}
{$ENDIF}

Тогда другая проблема - «План миграции», скажем, у меня есть 300 функций и в первом выпуске у меня будет всего 50 доступных в веб-приложении. Как отслеживать это? Я думал о (AB), используя интерфейсы Delphi, чтобы справиться с этим. Например, для аутентификации пользователя я могу переместить весь связанный код в процедуре и объявить интерфейс, как:

type
  IUserAuthentication= interface['{0D57624C-CDDE-458B-A36C-436AE465B477}']
    procedure UserAuthentication;
  end;

Таким образом, когда я реализую интерфейс IUSERAUTHENTECTICTION в обоих приложениях (толстый клиент и INTRAWEB), я знаю, что эта функция была «портирована» в Интернет. Во всяком случае, я не знаю, имеет ли этот подход смысл. Я сделал прототип, чтобы имитировать весь процесс. Он работает в приложении «Hello World», но мне интересно, имеет ли это смысл в большом приложении или эта идея интерфейса является только контрпродуктивным и может подняться.

Мой вопрос: имеет ли этот подход смысл? (Идея интерфейса - это просто дополнительная идея, она не так важна, как общая часть кода, описанная выше), это жизнеспособный вариант?

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

Дополнительный комментарий (Обновление): Я задаю этот вопрос, потому что, поскольку у меня нет приложения N-уровня, я вижу INTRAWEB как уникальный вариант для веб-приложения, который имеет общий код с толстым клиентом. Развивающиеся веб-сервисы из кода Delphi не имеют смысла в моем конкретном случае, поэтому альтернатива, у меня есть, это написать веб-интерфейс с помощью ASP.NET (дублирование бизнес-логики), но в этом случае я не могу воспользоваться общим кодом в Простой способ. Да, я мог бы использовать DLL, но мой код не подходит для этого.

Answer 1

Самое важное, что вы должны помнить, так это:

• Ваш толстый процесс клиента .exe используется одним человеком за раз (несколько человек будут иметь несколько экземпляров этого .exe).
• Ваш процесс INTRAWEB .exe будет использоваться многими людьми одновременно. Все они разделяют один и тот же экземпляр процесса.

Это означает, что ваша деловая логика должна быть не только рекакторироваться в общих единицах, экземпляры бизнес-логики должны быть в состоянии проживать в память несколько раз, а не вмешиваться.

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

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

Вы не должны забывать пользовательский интерфейс:

• Толстые клиенты поддерживают модальные формы и имеют много более богатых интерфейсов
• Веб-браузеры поддерживают только диалоговые окна сообщения (а затем: это очень ограничено), все модные пользовательские пользователи стоит много времени разработки (хотя, например, TMS имеет некоторые Хорошие компоненты для Intraweb)

Затем, чтобы повернуть его, вы должны справиться с природой безграждаемости протокола HTTP. Чтобы преодолеть это, вам нужны сеансы. Intraweb позаботится о большей части сессии.
Но вам нужно задать себе вопросы, как эти:

• Что должно произойти, если пользователь простаивает для XX минут?
• Сколько состояния сеанса я могу хранить в памяти? А что если это не подходит?
• Что я делаю с состоянием сеанса, который не вписывается в память?

Это всего лишь начало, поэтому давайте знать, если вам нужна дополнительная информация.
Если он очень специфичен для вашего приложения, вы всегда можете связаться со мной напрямую: просто Google Me.

- jereen.

Answer 2

Я думаю, что если вы переместите свое приложение к N-уровням, будет лучшее решение, после этого будет проще использоваться рабочим столом и веб-приложениями.

Вы уже сделали первую часть, развязав бизнес-логику из презентации, вы можете использовать Remobject. SDK или DataSnap, который в комплекте с Delphi.

После этого у вас будет работать приложение для рабочего стола, и вы можете использовать INTRAWEBM ASP.NET или, что когда-либо для веб-части, а таким образом вам не придется повторять дублирующую бизнес-логику для веб-части.

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