Web Client Software Factory and Dependency Injection - Feedback Needed on Service Registration via External Configuration File
by David Hayden ( Microsoft MVP C# ), Filed: Web Client Software Factory
In a past blog post:
Web Client Software Factory Needs Service Registration via External Configuration File
I mentioned that the only way to register services in the current version of the Web Client Software Factory is programmatically as such:
protected virtual void AddModuleServices
(IServiceCollection moduleServices)
{
moduleServices.AddNew<CustomerDataAccess,
ICustomerDataAccess>();
}
This means that whenever you want to change service providers for a service you need to modify source code, recompile, and publish the changes to the production environment. This limitation is counter intuitive to all the changes you see happening in ASP.NET, Enterprise Library, and the .NET Framework where you have the ability to swap out providers via a configuration file without having to touch source code and recompile.
Ideally we want something more like you get from common Dependency Injection and Inversion of Control tools that offer the ability to register services from an XML File:
<service
id="CustomerDataAccess"
service="ICustomerDataAccess, Core"
type="CustomerDataAccess, DataAccess"
lifestyle="singleton"
/>
This way we can change providers easily without modifying source code.
I was hoping a number of readers who use the WCSF would vote on the Issue in the Issue Tracker
Service registration through configuration
A few people did and the WCSF Team has proposed a solution for registering services via a configuration file which we are being discussing here:
HowTo: Registering services through configuration
If you have any interest in this topic, I urge you to be a part of the discussion and give your $0.02. The current proposal is a good start but a bit flawed in my opinion because there are two noticeable blemishes:
- Requires services to be registered in a particular order based on dependencies
- Requires use of an IConfigurable Interface to inject primitive dependencies similar to CAB
The use of IConfigurable seems to be based on a limitation of ObjectBuilder ( being implied anyway ) to inject a connectionString dependency as simple as this:
public class MyClass
{
private string _connectionString;
public MyClass(string connectionString)
{
_connectionString = connectionString
}
}
It sounds like the solution using IConfigurable would be more like the following where you get the connectionString as part of a NameValueCollection via a Configure Method:
public class MyClass : IConfigurable
{
private string _connectionString;
public MyClass()
{
}
public void Configure(NameValueCollection collection)
{
_connectionString =
(string)collection["connectionString"];
}
}
Now this will work, but it seems so unintuitive and not intention revealing. I prefer Constructor Injection on required dependencies because it reveals the intention - these dependencies are required! Setter Injector and use of IConfigurable implies optional dependencies which is not the case in this instance. The IConfigurable Interface seems contradictory to all other Dependency Injection Tools.
Anyway, I won't go into all my ranting, but this is a pretty important topic as Dependency Injection is a big part of the Web Client Software Factory and I don't want it screwed up. If you agree or disagree with me, share your thoughts in the forums so that the WCSF Team gets this right:
HowTo: Registering services through configuration
by David Hayden ( Microsoft MVP C# )
Filed: Web Client Software Factory