Hey
I am diving into the Service Builder and have a question about it and maybe a possible change to the code generator.
I think I understood the way, the service builder works and at the end I can run the code generator to get the basic implementation.
The ServiceName_Impl file is the one, I would like to talk about. There, all the methods are generated.
For example, like in you chat example, the code is generated:
public virtual string Login(string aUserID) {
}
this is fine, when I would like to implement my logic directly into this file, but each time, I regenerate the service, this implementation must be rewritten.
Wouldn’t it be a better solution to create the methods as Interface, so I can override the service and implement the interface there, so the logic within the method isn’t touched by the source code generator.
Or can I change the source code generator, that it would be done this way?
you shouldn’t regenerate _Impl file each time.
_Impl generator should be used only at the beginning.
later when you add/update/delete methods’ declarations you should reflect changes in _Impl only instead of generating this file from scratch.
Our codegen is open source.
as a result you can change it in any way - ROCodeGen at github
Hey EvgenyK
THX for your reply.
Your are right, that it shouldn’t be regenerated very often, but I think, in real life, and complex scenarios, when you create it from scratch, you will more often recreate the _Impl file to match, what you try to do.
And to copy/paste every time, isn’t much fun… - Also implementing the methods as Interface would allow to create a more structured developing environment. And not having one monolith like service file.
I will take a look into your Codegen on Github
THX a lot
Assuming the code in the first post is C# I would like to extend this discussion a bit.
In general there is no need to regenerate the _Impl file every time. Once you change the RODL the code gen auto-regenerates _Intf (interface) and _Invk (invoker) files for you. The Interface file contains, well, interface definition of the services defined in RODL. So once the one for these definitions is changed the code won’t compile at all until the service implementation class is updated to match its interface definition. So basically at every build attempt the compiler itself checks for you that the service implementation matches its definition and tells you which methods are missing or need to be amended.
Still there is 2 places where changes should be made (RODL and code itself) and this can be a bit annoying, especially during the active development phase.
And there is a solution for this problem: Code First services. This is the approach where you define your service class in code and server app itself regenerates its RODL at runtime. It is like you change the _Impl file and get the changes reflected in the RODL file automatically.
You say, that in general there is no need to regenerate the _Impl file every time.
I would agree to that, when I am finished with the development, but during the development, it definetly will happen, that the _Impl file must be regenerated, because of adding/changing the service itself.
The second thing is, what I try to avoid is, generating monolith “files”. Because every service is written in a single file.
This would be nice, when it got split (or the possibility for that), that every service gets its own _Impl file - > this would also avoid of overwriting an existing (probably working) file
The source generator creates Methods like in my first post (yes it is C#)
public virtual string Login(string aUserID) {
}
When I inherit from the generated file, the original generated code isn’t working, because Login does not create a return value (in the generated file). - So I would have to add some code here. - Next time of creation, it’s gone again… → With a huge backend, with about 100+ services, this would be very sad, to do that (even when it only happens once)
I think, that, when there also would be an option to let’s the methods create as an Interface, it would get much more independent.
The code first aproach makes the nice Interface you created with the Service Builder obsolete, and would again let me all write the code by my self…
There is a wizard that helps to convert a RODL-based server to a CodeFirst-based one
Hmm, what is your development pipeline that you use Service Builder to generate code files instead of relying on IDE? F.e. Visual Studio makes code files regeneration way easier and smoother.
a) These classes are not intended to be inherited from, they are used to hold the code itself. Ofc you can amend the code generator or the CodeDom tree it produces.
Take a look at the RODL sample - it shows how to generate code from a RODL library.
At the very least it produces a file-per-service _Impl files
It already does that. These interfaces are generated as part of the _Intf file.
- Also implementing the methods as Interface would allow to create a more structured developing environment. And not having one monolith like service file.