Using VCL for the Internet (intweb) as a trick to add a web interface to an inherited multilevel (2 level) Delphi win32 application makes sense?

Question

My team supports the huge Delphi Client Server win32 application. This is a client / server application (Thick Client) that uses DevArt (SDAC) components to connect to SQL Server.

Business logic is often a “trap” in Component event handlers, at least with some refactoring, it is able to move business logic in general units (most of this work has already been done during refactoring ... Maintaing outdated applications that someone wrote, very upset, but this is a very common job).

Now there is a web interface request, I have several options, of course, in this question I want to focus on VCL for the web interface (intra-user).

The idea is to use common code (the same pas files) for both the client-server application and the web application. I have heard of many people who moved legacy applications from delphi to intraweb, but here I am also trying to save the Thick client.

The idea is to use common code, maybe with some compiler directives to write specific code:

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

Then another problem is the “migration plan”, let's say I have 300 functions, and in the first release I will have only 50 of them available in the web application. How to track this? I was thinking about (ab) using Delphi interfaces to handle this. For example, to authenticate a user, I could move all the associated code in a procedure and declare an interface, for example:

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

Thus, when I implement the IUserAuthentication interface in applications (Thick Client and Intraweb), I know that this function has been "ported" to the Internet. In any case, I do not know if this approach makes sense. I created a prototype to simulate the whole process. It works for the Hello world application, but I wonder if it makes sense in a large application or if this idea of ​​an interface is only counterproductive and can have unpleasant consequences.

My question is: does this approach really make sense? (The idea of ​​an interface is just an additional idea, it is not as important as the general part of the code described above). Is this a viable option?

I understand that this depends on which application, in any case, is common for my CRM / Accounting domain, and the number of simultaneous users on one installation is usually less than 20 with peaks of 50.

ADDITIONAL COMMENT (UPDATE): I ask this question because, since I do not have an n-level application, I see Intraweb as a unique option for having a web application that shares code with a thick client. Developing web services from Delphi code does not make sense in my specific case, so the alternative I have is to write a web interface using ASP.NET (duplication of business logic), but in this case I can not use the general code in an easy way. Yes, I could use a DLL, perhaps, but my code is not suitable for this.

Answer 1

The most important thing you should remember:

• Your thick client process .EXE is used by one person at a time (several people will have multiple instances of this .EXE).
• Your intweb.EXE process will be used by many people at the same time. They all have the same process instance.

This means that your business logic should not only be reorganized into not only common units, but your business logic should be able to be in memory many times and not interfere.

It starts with a business logic that negotiates with a database: you should be able to connect to multiple databases at the same time (in practice, the database connection pool works best).

In my experience, when you can reorganize your business logic into datamodules, you have a good starting point to support both Intraweb and the thick client version of your application.

You should not forget about the user interface:

• Thick clients support modal forms and have a much richer user interface
• Web browsers only support message dialogs (and then: they are very limited), all fancy interface elements require a lot of development time (although, for example, TMS has nice components for Intraweb )

Then, to top it all, you need to deal with the nature of the HTTP protocol without statelessness. To overcome this, you need sessions. Intraweb will take care of most of the session.
But you should ask yourself the following questions:

• What happens if the user is idle for XX minutes?
• how much session state can be stored in memory? and what if it doesn't fit?
• What should I do with a session state that does not fit into memory?

This is just the beginning, so let me know when you need more information.
If it is very specific to your application, you can always contact me directly: just google me.

- Jeroen

Answer 2

I think that if you move the application to n-level, this will be the best solution, after that it will be easier to use desktop and web applications.

you have already done the first part, separating the business logic from the presentation, you can use the RemObject SDK or DataSnap, complete with Delphi.

after that you will have a working desktop application, and you can use Intrawebm Asp.net or something for the web part, and thus you do not have to duplicate the business logic again for the web part.

usually converting a desktop application to the Internet is not as easy as you thought, because they work in different environments, and you need to build each in its nature.