moving a class implementation from desktop to server

[David Schwartz 426]

I'm looking for some insights on how people think about this....

 

I've been building a prototype to test out different things, and have some classes in units that do certain things.

 

Now I'm thinking of moving them out to remote services (on a REST server somewhere).

 

I realize a lot of web services are built from scratch to be that, but I like building a VCL-based app to test everything in one piece, then split it up. Does anybody else do that?

 

I'd like to have minimal changes to the class interfaces (properties and methods), perhaps just by adding security-related details where needed.

 

In my mind, I'd like to be able to sprinkle in a few attributes here and there, then copy the class to a different unit that runs on a REST server, set a flag in each unit, and the local implementation would effectively be stubbed out and replaced with calls to the remote service.

 

I don't know if this would be a function of adding an Interface and some property attributes, or if it needs to work in conjunction with a particular web service (I'm using TMS XData), or something else.

 

I suspect some folks here have actually done this, and I'm curious what they have to say about their effort.

[Attila Kovacs 629]

15 minutes ago, David Schwartz said:

I realize a lot of web services are built from scratch to be that, but I like building a VCL-based app to test everything in one piece, then split it up. Does anybody else do that?

 

Of course. Every new feature, mostly in console apps if it's possible. The result can be tested and easily moved to a lib or other projects.

[Angus Robertson 574]

All of my Windows service applications are built as dual desktop/services, with a minimal GUI, TMemo and a couple of buttons, so they can be fully debugged in Delphi and also installed to run as background services. 

 

20 years ago I used the Aldyn SvCom service framework, now I use DDService.  ICS includes a REST web server sample using DDService.

 

Angus

 

[David Schwartz 426]

Just to be clear, I'm talking about starting out with a normal VCL app with some classes that do specific things, each in their own units, and the resulting EXE works fine. No Windows Services are being used, and the classes are just normal classes, not specifically designed to run as remote services.

 

Now what I want to do is "stretch" the classes out with minimal changes to their interfaces so the implementation part is effectively moved over to a REST-based HTTP service somewhere (not a Windows Service). Initially it would probably be tested under a localhost web server.

 

Perhaps we can call this a form of REFACTORING?

 

I worked with a TDataSet library once (forget the name) where you could build your app on the local machine and it connected to a DB server somewhere. You'd set it up in a DataModule and add your logic there. It had a feature where you could set a flag, add a remote IP address, set up a name and pwd for security, then build another app that ran as a Windows service that used the same DataModule, set a flag in that one to say it was the other side of the connection, running on the appointed IP, and viola! You just moved all of the logic into a middle tier service. (Yes, I know this used a proprietary channel and the remote side ran as a Windows Service. I'm pointing to the CONCEPT, not this specific implementation. I want to use a REST-based HTTP service.)

 

I'm curious if there's any way to do something similar without using a TDataSet? Just JSON going through a REST interface to a remote HTTP service ... or something along that line ?

 

 

[Attila Kovacs 629]

51 minutes ago, David Schwartz said:

I'm curious if there's any way to do something similar without using a TDataSet?

Yes. HTTP.

 

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

 

 

[David Schwartz 426]

18 minutes ago, Attila Kovacs said:

Yes. HTTP.

 

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

 

That's what I said in the first place.

 

Quote

REST stands for REpresentational State Transfer. REST is web standards based architecture and uses HTTP Protocol. It revolves around resource where every component is a resource and a resource is accessed by a common interface using HTTP standard methods. 

Google

 

It still does not address the question I asked. 

 

How have YOU gone about splitting up a working class in a single Delphi app so the interface is preserved and the implementation resides at the other end of REST-based HTTP channel?

 

I'm not asking, "is it possible?" or "has it been done?" I _know_ it's possible and HAS been done -- just not by me. I'm looking for people who have actually done it and can offer any insights into what they learned. 

 

So what did YOU do and what did YOU learn when you did it?

 

 

 

Edited December 25, 2022 by David Schwartz

[Attila Kovacs 629]

Quote

So what did YOU do and what did YOU learn when you did it?

It's the same if you let's say, would split out the very same functionality into a console app.

It will cost you a lot of refactoring. A lot. But with time, you will get the idea, how to arrange your units and classes for the future.

I don't know what I have learned, maybe not to be afraid creating units. A lot of units.

 

Edited December 25, 2022 by Attila Kovacs

[Alexander Elagin 143]

Just be sure that you never ever implement any business logic in visual form units (you know, those OnClick handlers...). Everything must be implemented in non-visual classes (including datamodules) not depending on any VCL units. Forms must be used only to call that functionality and display the results, if any. Thus you will finally get a nice set of units which can be further used anywhere, be it a UI-less server, console application, VCL or FMX.

[Fr0sT.Brutal 900]

I've never did things like these but I'd start with wrapping the methods into some abstract class keeping in mind it could be of any nature. In your example, that TDataset wrapper shouldn't rely on sync behavior to incorporate async REST requests later (you unlikely want to have sync REST requests). Or it could leave async things for the caller app.

Anyway that's what the whole encapsulation and module division is about - have the single function call and don't care what's inside.

Edited December 26, 2022 by Fr0sT.Brutal