Description
Three separate validators contain nearly identical validation logic (~200 lines each):
src/Servy/Validators/ServiceConfigurationValidator.cs (~226 lines)
src/Servy.Manager/Validators/ServiceConfigurationValidator.cs (~216 lines)
src/Servy.CLI/Validators/ServiceInstallValidator.cs (~176 lines)
All three check the same fields in the same order: Name, ExecutablePath, paths, timeouts, rotation, health monitoring, failure program, env vars, dependencies, credentials, pre/post-launch/stop hooks. Only the error reporting mechanism differs (MessageBox vs CommandResult).
Estimated redundant lines: ~600
Suggested fix
Extract a shared ServiceValidationRules class in Servy.Core that returns a list of validation errors. Each project's validator becomes a thin wrapper feeding errors to its own UI mechanism.
Description
Three separate validators contain nearly identical validation logic (~200 lines each):
src/Servy/Validators/ServiceConfigurationValidator.cs(~226 lines)src/Servy.Manager/Validators/ServiceConfigurationValidator.cs(~216 lines)src/Servy.CLI/Validators/ServiceInstallValidator.cs(~176 lines)All three check the same fields in the same order: Name, ExecutablePath, paths, timeouts, rotation, health monitoring, failure program, env vars, dependencies, credentials, pre/post-launch/stop hooks. Only the error reporting mechanism differs (MessageBox vs CommandResult).
Estimated redundant lines: ~600
Suggested fix
Extract a shared
ServiceValidationRulesclass inServy.Corethat returns a list of validation errors. Each project's validator becomes a thin wrapper feeding errors to its own UI mechanism.