将Delphi应用程序转换为作为服务运行-是否有必要?

有商业(和 free )解决方案如 Firedaemon ,它将(几乎)作为服务运行任何应用程序。

顺便说一句,分离逻辑和用户界面并不难——在开发应用程序时应该已经这样做了。仅仅因为Delphi使在与用户界面相关的代码背后编写业务逻辑变得容易,这并不意味着您真的应该这样做。看看演示模式 Martin Fowler's site .

我通常以这样的方式创建我的应用程序:它可以通过命令行开关作为服务或GUI启动。 /GUI .

当应用程序使用GUI运行时,我会“手动”实例化并启动服务类。

优势:

• 它将运行相同的代码,使调试服务变得非常容易。您可以只放置断点并单步执行代码,而不必“附加”到正在运行的应用程序。

• 由于使用了GUI,您可以通过列表视图和按钮,甚至在没有调试器的远程服务器上,看到您的服务将要做什么,并与之交互。必须通过日志和配置与您的服务进行交互是很糟糕和缓慢的。

示例DPR,来自这样工作的项目:

program xxxx;

uses 
  SysUtils,
  SvcMgr,
  .......;

{$R *.res}

begin
  GlobalAppId := 1;
  MapMatcherController := TMapMatcherController.Create(nil);
  try
    if FindCmdLineSwitch('GUI',['/','-'],True) then
    begin
      Forms.Application.Initialize;
      Forms.Application.MainFormOnTaskbar := True;
      Forms.Application.CreateForm(TfrmMain, frmMain);
      Forms.Application.Run;
    end
    else
    begin
      SvcMgr.Application.Initialize;
      SvcMgr.Application.CreateForm(TsrvMapMatcher2, srvMapMatcher2);
      SvcMgr.Application.Run;
    end;
  finally
    MapMatcherController.Free;
 end;
end.

哦,要记住的另一件事是,服务通常作为“系统”用户运行,这意味着您将拥有不同的特权和设置(例如驱动器号映射)。

一般来说,可以有一个混合的单个exe,它反过来作为一个服务运行,或者作为一个完整的GUI标准应用程序运行。

您的应用程序需要多大的努力来适应这一类别取决于它是如何设计的,特别是它在业务逻辑和用户界面逻辑之间的耦合。

Delphi本身就是这种应用程序的一个很好的例子: SCKTSRVR.EXE 在$delphi\bin目录中,以GUI应用程序或服务的形式运行(运行scktsrvr.exe/install以自动注册服务并使用管理控制台启动/停止服务)。

在$delphi\source\db文件夹中,您将找到项目文件(scktsrvr.dpr/res、scktcnst.pas、scktmain.pas/dfm)。花点时间检查一下是怎么做的,谁知道呢…也许这就是你要找的申请表。

从Windows Vista开始考虑 交互式服务 不允许在他/她的桌面上与用户交互。管理员必须启用 交互式服务检测 用户必须切换到会话0桌面才能与您的服务交互(通过交互,它意味着查看和与您的服务表单交互)

您可以尝试使用svrany,这是一种将应用程序作为服务运行的工具。 它是服务器资源工具包工具的一部分。 try this link for 2003 server resource kit download .

这取决于您的应用程序,但一般来说是可以实现的。试试这个: http://iain.cx/src/nssm . 在将应用程序作为服务启动之前,不要忘记启动应用程序所依赖的所有服务。谷歌周围的信息如何做到这一点。

您可以编写一个启动应用程序的简单服务。但是如果你关心你的应用程序的未来,我会选择服务的方式。是的,您必须将应用程序分为两部分,客户机/GUI部分和服务本身,特别是由于Vista和7的安全性,使得服务更难显示用户界面。 服务有几个优点,它们在各自的会话中运行,它们可以设置为使用与登录用户不同的给定用户运行,只有具有适当权限的用户才能控制它们,Windows可以在它们失败时自动重新启动它们(或执行其他操作)。