使用Delphi实现win32应用程序的动态流程图

发布于 2024-11-13 11:04:21 字数 856 浏览 2 评论 0原文

Delphi XE、Win32 应用程序、SQL Server 2005 数据库。

我正在实施质量管理体系。 我有一些预定义的流程图可以将它们应用到我的应用程序/系统中。我被要求将所有事务(我不确定它是否是正确的词)动态化,因此每当它们修改流程图时,它都会影响应用程序(当然无需重新编译或任何补丁)

这是一个示例,可以更清楚地解释:

假设一个文档控制模块,我们有一个流程图如下:

  1. [文档控制器] 从承包商处接收文档
  2. [文档控制器] 使用清单检查文档
  3. [文档控制器] 将文档发送到 [项目经理]
  4. [项目] [项目经理] 应用文档中的操作
  5. [项目经理] 将文档发送到 [文档控制器]
  6. [文档控制器] 归档文档。

现在应用程序应该从数据库中读取其功能的参数。 假设已收到并检查了文档(1 和 2),现在发送它。一旦按下“保存”按钮,系统就会检查谁应该是该文档的接收者并将文档发送给他/她。 在我们的示例中,接收者是[项目经理]。然而,稍后他们可能会决定将流程图更改为 - “3- [文档控制者] 将文档发送给 [项目架构师]”。 因此,系统应按照流程图中的定义运行。

我想知道实现这样的系统(Delphi XE,win32)的正确方法是什么?

我有一些想法,但不确定它是否正确: 对于流程图中的每个流程,我可以定义一个具有唯一 ID 的服务,然后从数据库读取该服务并在应用程序层中调用它(带有相关参数)。在这种情况下,我不确定每个服务是否应该是一个 dll 文件或包文件,并且我认为拥有这么多库文件是错误的,因为服务不会很少!

我希望我能很好地解释我的问题,如果太长,抱歉。 如果不清楚,请告诉我。

谢谢,
摩耶

Delphi XE , Win32 Application , SQL Server 2005 Database.

I am implementing a Quality Management System.
I have some predefined Process Maps to apply them inside my application/system. I am requested to have all the transactions (I am not sure if it is correct word for it) dynamic so whenever they modify the process maps it affects the application (Without recompilation or any patches of course)

Here is an example to explain more clear:

Assume a Document controlling module, We have a process map as :

  1. [Document Controller] Receives the document from Contractor
  2. [Document Controller] Checks the document with the checklist
  3. [Document Controller] Sends the document to the [Project Manager]
  4. [Project Manager] applies and Action in the document
  5. [project Manager] Sends the document to [Document Controller]
  6. [Document Controller] Archives the document.

Now application should read the parameters from a database for its functions.
Let’s say Received and Checked the document (1 and 2) and now sends it. As soon as the “Save” Button is pressed the system should check who should be the receiver of this document and send the document to him/her.
In our example, the receiver is the [project Manager]. however, sometime later they might decide to change the process map as
- “3- [Document Controller] sends the document to the [Project Architect]”.
Therefore, the system should act as defined in the process map.

I am wondering what Is the proper way to implement such system (Delphi XE , win32)?

I have some idea but not sure if it is proper :
For each Process in the process map I can define a Service with a kind of unique Id and I read the service from the database and call it in the application layer (with relevant Parameters). In this case I am not sure if each service should be a dll or package file and I believe it is wrong to have that number of library files, since the services are going to not very few!

I hope I could explain my problem well and sorry if it is too long.
Please let me know if it is not clear.

Thanks,
Mahya

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

雅心素梦 2024-11-20 11:04:21

在我看来,您想为应用程序执行的每个“业务功能”应用一些通用规则,从而实现某种形式的质量管理。我将使用“业务功能”来表示可能跨越源代码中的多个技术功能和过程的逻辑操作。

没有明确的“正确方法”,但有些想法比其他想法更好。

使用数据库来存储动态数据显然是一个好主意。例如,您可以将每个业务功能建模为一个单独的实体(每个业务功能有一个数据库记录)。无论您需要什么变量来管理每个业务功能的处理,都将确定必要的字段。您肯定需要为每个人提供一个唯一的 ID。

没有理由将业务功能编码到单独的 dll 中,但我会将它们放在源代码中的单独单元中,或者根据功能的操作类型或对您的业务有意义的其他一些逻辑分组来对功能进行分组。您需要更改调用业务功能的方式。您需要间接调用它们,换句话说,您将调用通用的 PerformFunction 例程,可能会以适合您的任何数据结构传递函数标识符和一些其他参数。随着数据库中参数的更改(根据您的示例,将文档发送给谁,项目经理还是项目架构师?),只要您实现了所有可能的排列,业务功能的操作就会相应地修改考虑到每个业务功能的变量数量,可能会出现这种情况。我确信文档收件人的电子邮件地址并不是您所想到的全部。这是一些可能有帮助的代码。我并不是说这是好的代码,只是为了传达想法。

type
  TFunctionRuntimeParameter = record
    FunctionID: integer; // this better be unique
    FunctionName: string;  // something intelligible for display purposes
    ReportToEmail: string; // who to send the end report document
    AuditLevel: integer;  // for example vary the degree of auditing/logging
    variableABC: TDateTime;  // could be a date that influences something
  end;

function TMyForm.GetRuntimeParametersFromDB(aFunctionID: integer): TFunctionRuntimeParameters;
var
  tempResult: TFunctionRuntimeParameters;
begin
  // For brevity I'm going to assume an existing query object connected to your db.
  qry.SQL.Add('Select * From BusinessFunctions Where Function_ID = :FunctionID');
  qry.ParamByName('FunctionID').AsInteger := aFunctionID;
  qry.Open;
  tempResult.FunctionID := qry.FieldByName('Function_ID').AsInteger; // don't ask me Y!
  tempResult.FunctionName := qry.FieldByName('Function_Name').AsString;
  tempResult.ReportToEmail := qry.FieldByName('Report_To_Email').AsString;
  tempResult.AuditLevel := qry.FieldByName('Audit_Level').AsInteger;
  tempResult.variableABC := qry.FieldByName('ABC').AsDateTime;
  result := tempResult;
  qry.Close;
end;

procedure TMyForm.PerformFunction(aFunctionID: integer; FRP: TFunctionRuntimeParameters);
var
  MyReportDocument: TMyReportDocument;
begin
  if (FRP.AuditLevel > 0) then
    // do something special before starting the function

  case aFunctionID of
    101: MyReportDocument := DoBusinessFunctionABC;
    102: MyReportDocument := DoBusinessFunctionDEF;
    103: MyReportDocument := DoBusinessFunctionXYZ;
  end;

  SendReportDocumentByEmailTo(MyReportDocument, FRP.ReportToEmail);

  if ((Now - FRP.variableABC) > 28) then
    // perhaps do something special every 4 weeks!

  if (FRP.AuditLevel > 0) then
    // do something special after the function has finished
end;

procedure TMyForm.btnBusinessFunctionXYZClick(Sender: TObject);
var
  FunctionID: integer;
  FunctionRuntimeParameters: TFunctionRuntimeParameters; // record that mimics db entry
begin
  FunctionID := 1234; // or you might prefer an enum
  FunctionRuntimeParameters := GetFunctionRuntimeParametersFromDB(FunctionID);
  PerformFunction(FunctionID, FunctionRuntimeParameters);
end;

这样,当数据库中的运行时参数发生更改时,应用程序的行为将有所不同,而无需重新编译。

It sounds to me like you want to apply some common rules for every "business function" performed by your application, thereby implementing some form of quality management. I'm going to use "business function" to denote a logical operation that may span several technical functions and procedures in the source code.

There is no defined "proper way", but some ideas are better than others.

The use of a database to store dynamic data is obviously a good idea. For example you can model each business function as a separate entity (with one database record per business function). Whatever variables you'll need to manage the processing of each business function will determine the necessary fields. You'll definitely need a unique id for each one.

There's no reason to code the business functions into separate dlls, but I'd put them in separate units in the source code or maybe group the functions according to their type of operation or some other logical grouping that makes sense to your business. You'll need to change the way you call your business functions. You'll need to call them indirectly, in other words you would call a generic PerformFunction routine, perhaps passing a function identifier and some other parameters in whatever data structure suits you. As the parameters are changed in the database (according to your example, who to send the Document to, Project Manager or Project Architect?) the operation of the business function will be modified accordingly as long as you've implemented all the possible permutations that could arise given the number of variables for each business function. I'm sure the Document Recipient's email address isn't all you have in mind. Here's some code that might help. I'm not saying it's good code, it's only to convey the idea.

type
  TFunctionRuntimeParameter = record
    FunctionID: integer; // this better be unique
    FunctionName: string;  // something intelligible for display purposes
    ReportToEmail: string; // who to send the end report document
    AuditLevel: integer;  // for example vary the degree of auditing/logging
    variableABC: TDateTime;  // could be a date that influences something
  end;

function TMyForm.GetRuntimeParametersFromDB(aFunctionID: integer): TFunctionRuntimeParameters;
var
  tempResult: TFunctionRuntimeParameters;
begin
  // For brevity I'm going to assume an existing query object connected to your db.
  qry.SQL.Add('Select * From BusinessFunctions Where Function_ID = :FunctionID');
  qry.ParamByName('FunctionID').AsInteger := aFunctionID;
  qry.Open;
  tempResult.FunctionID := qry.FieldByName('Function_ID').AsInteger; // don't ask me Y!
  tempResult.FunctionName := qry.FieldByName('Function_Name').AsString;
  tempResult.ReportToEmail := qry.FieldByName('Report_To_Email').AsString;
  tempResult.AuditLevel := qry.FieldByName('Audit_Level').AsInteger;
  tempResult.variableABC := qry.FieldByName('ABC').AsDateTime;
  result := tempResult;
  qry.Close;
end;

procedure TMyForm.PerformFunction(aFunctionID: integer; FRP: TFunctionRuntimeParameters);
var
  MyReportDocument: TMyReportDocument;
begin
  if (FRP.AuditLevel > 0) then
    // do something special before starting the function

  case aFunctionID of
    101: MyReportDocument := DoBusinessFunctionABC;
    102: MyReportDocument := DoBusinessFunctionDEF;
    103: MyReportDocument := DoBusinessFunctionXYZ;
  end;

  SendReportDocumentByEmailTo(MyReportDocument, FRP.ReportToEmail);

  if ((Now - FRP.variableABC) > 28) then
    // perhaps do something special every 4 weeks!

  if (FRP.AuditLevel > 0) then
    // do something special after the function has finished
end;

procedure TMyForm.btnBusinessFunctionXYZClick(Sender: TObject);
var
  FunctionID: integer;
  FunctionRuntimeParameters: TFunctionRuntimeParameters; // record that mimics db entry
begin
  FunctionID := 1234; // or you might prefer an enum
  FunctionRuntimeParameters := GetFunctionRuntimeParametersFromDB(FunctionID);
  PerformFunction(FunctionID, FunctionRuntimeParameters);
end;

This way as the Runtime Parameters change in the database, the application will behave differently without the need for recompilation.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文