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

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

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

Теперь есть запрос веб-интерфейса, у меня есть несколько вариантов, конечно, в этом вопросе я хочу сосредоточиться на VCL для сети (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;

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

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

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

ДОПОЛНИТЕЛЬНЫЙ КОММЕНТАРИЙ (ОБНОВЛЕНИЕ): я задаю этот вопрос, потому что, поскольку у меня нет n-уровневого приложения, я вижу Intraweb как уникальную возможность иметь веб-приложение, имеющее общий код с толстым клиентом. Разработка веб-сервисов из кода Delphi не имеет смысла в моем конкретном случае, поэтому у меня есть альтернатива - написать веб-интерфейс с использованием ASP.NET (дублируя бизнес-логику), но в этом случае я не могу воспользоваться преимуществами общего кода в Простой способ. Да, я мог бы использовать dll, может быть, но мой код не подходит для этого.

Источник

2 ответа

Решение

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

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

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

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

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

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

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

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

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

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

--jeroen

Источник

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

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

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

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

Источник
Другие вопросы по тегам