CodeFirst and Client-Side interfaces - Generates only one interface file


(Smokoveck Florencio) #1


I am converting my server to CodeFirst model, I’m with the following client side doubt: I have several services in my project server, so I have several interfaces files (_Intf.pas), the units (Forms, DataModules) of client side makes uses of the various files of server interfaces. With the CodeFirst model it automatically generated only one interface file with all the services, that is to say that I have to remove all the uses of the interfaces and replace with the uses of this new interface file? Otherwise, would it be possible to generate an interface unit for each service?

I tried to specify the service name in the url (http://localhost:8099/bin?service=DEPART) but it still generates all the services. I would like it to generate only DEPART_Intf for example.

Best regards,

(marc hoffman) #2

Right now, for a CodeFirst service, there’s only the option to get a single RODL generated by the server at runtime, resulting in a single _Intf unit generated when importing it. What’s your exact use case/expectation for for why you’d need an _Intf that does not contain all services and types? The client can simply use the classes it needs, and ignore those it doesn’t (and the linker, if were talking Delphi, would even eliminate the unused classes from the final binary).

We could probably add an option to do a “partial” import, but I’d like to understand the exact problem you’re trying to solve, before we look at that…


(Smokoveck Florencio) #3

At principle the only problem is conventer effort, because my project is too big, I’ll have to do something to remove the all _intf files from the uses session and add the new interface file.

Okay, I will make these changes and any problem I’ll call you back.


(marc hoffman) #4

Shouldn’t that almost be a search-and-replace operation?


(Smokoveck Florencio) #5

Hi Marc

Problems with single interface file:

Scenario: The server structure consists of 16 modules DLL’s (Hrydra Modules) with a total of 280 services (DataAbstractService).

  • To generate a single interface file takes about 3 minutes to be generated file and 5 minutes to compile. always a service is changed, this can compromise productivity.

  • The generated file has 65MB with 1.771.724 lines.

  • Some class names or enumerators are duplicates because of the several services and methods, this was not a compile problems when we had an interface for each service, with the single interface duplication generates a compile problems.

It would be very important for my project that it would be possible to have the option of generating the interface files separated by service.

What scenario would be the best solution?

Would it be possible to create a program that extracts the interfaces separated by service?

What scenario would be the best solution?

Would it be possible to create a program that extracts the interfaces separated by service?

It would be very important for my project that it would be possible to have the option of generating the interface files separated by service, so we would not have any changes on the client side.

Best regards,


(marc hoffman) #6

Ouch, ok. I can see the dilemma.

I can see two solutions:

  • longer term, we can look at supporting “filtered” import in ServiceBuilder and the Idea tools, giving you an option to select the interfaces you need.

  • short term, our codegen is all open source, available at (you’ll also need So you could go ahead grab the source code for the rodl2code tool and modify it or create your own custom frontend to the ROCodeGen API that does exactly what you need.

In essence, look at and change it to adjust the functionality, for example by deleting the types you don’t want imported from the loaded RODL structure in memory, before passing it to the codegen.

how does that sound?

(EvgenyK) #7


You can split your big RODL to a lot of small RODL and later include all of them into one RODL using use existing RODL feature, something like:

as a result, after modifying, say, rodl3 you can manually recreate correspondent _Intf so you will have a lot of small unchanged files instead of one big file that contains a lot of lines and which is recompiled at each compiling.

(Smokoveck Florencio) #8


I will study the code and try to make the changes I need.

Can you please send me of the issue number of this improvement?

Thank you very much.

(Smokoveck Florencio) #9


I did not understand with that I would solve my problem. I already had small interfaces, separated for each service, but when converting to CodeFirt, on the client side, when I regenerate the interface, the result is a single interface with every service, separating this manually would be very unviable.


(EvgenyK) #10

Sorry, I missed what you have code-first based services
my solution will work for RODL-based services.

(Smokoveck Florencio) #11

Hi Marc,

I was thinking of doing something more simpler, even outside of the delphi IDE, a small program that could read and generate separate interfaces for services. Would it have any small sample project or any documentation of what it would take to make an application that would do this?


(marc hoffman) #12

I do, that’s exactly what this would be:

(Smokoveck Florencio) #13


Please, are you working to add this option (generate the interface files separately per service)?



(EvgenyK) #18


you can try this workaround: import RO server into Service Builder, remove unneeded services and perform Tools->Delete unused items.
you should receive service and structs that are used in service methods

(Smokoveck Florencio) #19


The problem is that I have several services and separate each service manually is not simple and this would also have to be done every time I had some changes in the services.

(EvgenyK) #20

What do you think about this idea?

Some attribute, like ROServiceGroup(name), can be added to code-first objects (services, structs, arrays, exceptions, etc) and then at requesting http://localhost:8099/rodl?servicegroup=Group1, server will generate RODL with all objects that contain this attribute.

it should solve your issue

(Smokoveck Florencio) #21

Yeah :smile: this can solve, I will need to generate all the services in the migration for code-first but then I will only need to regenarate of the service that is changed.

Please, this feature would solve my problem.


(RemObjects) #22

Thanks, logged as bugs://81427

(RemObjects) #23

Thanks, logged as bugs://81428

(EvgenyK) #24

some progress with it

  • for RODL-based version, it was implemented via custom attributes:
<ROServiceGroups Value="group1,group2" />
  • for Code-First version, via ROServiceGroup attriibute:
  TNewService1 = class(TRORemotable)