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
In the current Cocona framework, command-line options are accessible primarily within command methods.
This design limits scenarios where global command-line options need to influence the application's setup and service configuration before any command execution.
Proposed Feature:
I propose a feature that allows global command-line options to be parsed and made available during the ServiceCollection initialization phase.
This would enable the use of command-line options for configuring services and other setup processes that occur before command execution.
Use Case Example:
A practical example is configuring a DatabaseFactory class that requires a connection string to create a DBConnection.
The connection string should ideally be provided as a global command-line option.
However, in the current Cocona framework, there's no straightforward way to pass this connection string from the command-line options to the DatabaseFactory service without involving command methods.
Current situation implementation:
publicinterfaceIOracleConnectionFactory{
OracleConnection Create();}publicclassOracleConnectionFactory:IOracleConnectionFactory{privatestring?_connectionString;public OracleConnection Create(){if(_connectionString isnull)thrownew InvalidOperationException("Connection string is not set.");returnnew OracleConnection(_connectionString);}publicvoidSetConnectionString(stringconnectionString){_connectionString=connectionString;}}publicinterfaceIMyRepository{voidDoSomethingWithDb();}publicclassMyRepository:IMyRepository{publicreadonlyIOracleConnectionFactory_connectionFactory;publicMyRepository(IOracleConnectionFactoryconnectionFactory){_connectionFactory=connectionFactory;}publicvoidDoSomethingWithDb(){usingvarconnection= _connectionFactory.Create();
connection.Open();// do something with the connection}}publicclassMyCommands{privatereadonlyOracleConnectionFactory_connectionFactory;privatereadonlyIMyRepository_myRepository;publicMyCommands(OracleConnectionFactoryconnectionFactory,IMyRepositorymyRepository){_connectionFactory=connectionFactory;_myRepository=myRepository;}publicvoidDoSomethingCommand([Option('c', Description ="The connection string")]stringconnectionString){
_connectionFactory.SetConnectionString(connectionString);
_myRepository.DoSomethingWithDb();}}publicclassProgram{publicstaticvoidMain(string[]args){varbuilder= CoconaApp.CreateBuilder();
builder.Services.AddSingleton<OracleConnectionFactory>();
builder.Services.AddSingleton<IOracleConnectionFactory>(sp => sp.GetRequiredService<OracleConnectionFactory>());
builder.Services.AddTransient<IMyRepository,MyRepository>();varapp= builder.Build();
app.AddCommands<MyCommands>();
app.Run();}}
In this scenario, the DoSomethingCommand method in MyCommands is responsible for setting the connection string in the OracleConnectionFactory. This approach mixes the concerns of command logic and service configuration, which is not ideal.
Ideal implementation
publicinterfaceIOracleConnectionFactory{
OracleConnection Create();}publicclassOracleConnectionFactory:IOracleConnectionFactory{privatestring_connectionString;publicOracleConnectionFactory(GlobalOptionsglobalOptions){_connectionString= globalOptions.ConnectionString;}public OracleConnection Create(){returnnew OracleConnection(_connectionString);}}publicinterfaceIMyRepository{voidDoSomethingWithDb();}publicclassMyRepository:IMyRepository{publicreadonlyIOracleConnectionFactory_connectionFactory;publicMyRepository(IOracleConnectionFactoryconnectionFactory){_connectionFactory=connectionFactory;}publicvoidDoSomethingWithDb(){usingvarconnection= _connectionFactory.Create();
connection.Open();// do something with the connection}}publicclassMyCommands{privatereadonlyIMyRepository_myRepository;publicMyCommands(IMyRepositorymyRepository){_myRepository=myRepository;}publicvoidDoSomethingCommand(){
_myRepository.DoSomethingWithDb();}}publicclassGlobalOptions{[Option('c', Description ="The connection string")]publicstringConnectionString{get;set;}}publicclassProgram{publicstaticvoidMain(string[]args){varbuilder= CoconaApp.CreateBuilder();
builder.AddGlobalOptions<GlobalOptions>()
builder.Services.AddSingleton<IOracleConnectionFactory,OracleConnectionFactory>);
builder.Services.AddTransient<IMyRepository,MyRepository>();varapp= builder.Build();
app.AddCommands<MyCommands>();
app.Run();}}
Conclusion:
This feature would greatly enhance Cocona's usability for applications where command-line options are integral to the configuration and setup.
It aligns with the principles of separation of concerns and would be a valuable addition to Cocona's capabilities.
The text was updated successfully, but these errors were encountered:
Problem Statement:
In the current Cocona framework, command-line options are accessible primarily within command methods.
This design limits scenarios where global command-line options need to influence the application's setup and service configuration before any command execution.
Proposed Feature:
I propose a feature that allows global command-line options to be parsed and made available during the ServiceCollection initialization phase.
This would enable the use of command-line options for configuring services and other setup processes that occur before command execution.
Use Case Example:
A practical example is configuring a DatabaseFactory class that requires a connection string to create a DBConnection.
The connection string should ideally be provided as a global command-line option.
However, in the current Cocona framework, there's no straightforward way to pass this connection string from the command-line options to the DatabaseFactory service without involving command methods.
Current situation implementation:
In this scenario, the DoSomethingCommand method in MyCommands is responsible for setting the connection string in the OracleConnectionFactory. This approach mixes the concerns of command logic and service configuration, which is not ideal.
Ideal implementation
Conclusion:
This feature would greatly enhance Cocona's usability for applications where command-line options are integral to the configuration and setup.
It aligns with the principles of separation of concerns and would be a valuable addition to Cocona's capabilities.
The text was updated successfully, but these errors were encountered: