You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Server starts and load from files through DI container instead of what is conventional: loading after the DI container is fully resolved. Types registered in a DI container should not do IO until asked for by code that takes dependency on said types.
The dependency-flow on data is inverted from what it should be (is parent->child but should be child->parent). Types like WorldPersistence should take dependency on Server (which knows its SaveName) instead of recomputing the save location. The current situation has lead to awkward DI container setup where types need to run setup code to be able to register in the DI container.
Strongly related with 2: because file loading happens during DI container setup, cancellation of server is hard to implement (without first waiting for the server to fully load).
Rename the Server class to ServerService, extending BackgroundService. Have it figure out the save name from command line arguments (passed to the server executable).
Create a ConfigService which depends on ServerService and loads in the right server.cfg file based on the save name that ServerService knows. Any updates to the configuration should happen through this ConfigService.
Create a WorldPersistenceService which depends on ServerService to figure out where it should Load, Save and Backup to. If there is no world, have it create one in WorldPersistenceService.StartupAsync routine. Add events/dependencies to other services as needed to trigger world backups or saving.
Create a CommandService that will read from the command line and call the correct command on submit (i.e. enter pressed).
Continue creating APIs that depend on ServerService or any other as needed...
Describe the issue
Server code has the following code smells:
WorldPersistence
should take dependency onServer
(which knows its SaveName) instead of recomputing the save location. The current situation has lead to awkward DI container setup where types need to run setup code to be able to register in the DI container.To assist with this refactor, the server should implement .NET Generic Host API.
Then:
Server
class toServerService
, extendingBackgroundService
. Have it figure out the save name from command line arguments (passed to the server executable).ConfigService
which depends onServerService
and loads in the right server.cfg file based on the save name thatServerService
knows. Any updates to the configuration should happen through thisConfigService
.WorldPersistenceService
which depends onServerService
to figure out where it shouldLoad
,Save
andBackup
to. If there is no world, have it create one inWorldPersistenceService.StartupAsync
routine. Add events/dependencies to other services as needed to trigger world backups or saving.CommandService
that will read from the command line and call the correct command on submit (i.e. enter pressed).ServerService
or any other as needed...PRs required before work can start
#1848
The text was updated successfully, but these errors were encountered: