Comments (3)
#143 added some overloads for the Register
method:
void Register<TImplementation>(...)
void Register<TService1, TImplementation>(...)
void Register<TService1, TService2, TImplementation>(...)
void Register<TService1, TService2, TService3, TImplementation>(...)
void Register<TService1, TService2, TService3, TService4, TImplementation>(...)
I believe up to 4 services for a given implementation should cover all sensible use cases. Furthermore this way it was possible to add generic constraints to all of these methods for some extra compile time safety.
Also in this PR TImplementation is now also registered as a service type which will allow you to resolve TImplementation directly and with the correct lifetimes etc.
The As
method was removed as its no longer needed.
With this change we can close this issue.
from singularity.
There are two aspects of the registration API I think can be improved:
There are two ways of defining a dependency type
- By passing the dependency type as a parameter into
Register(Type dependencyType, Type instanceType, ...)
orRegister<TDependency, TInstance>(...)
. - By using
As
on eitherWeaklyTypedServiceConfigurator
orStronglyTypedServiceConfigurator<TDependency, TInstance>
.
Only the latter one allows for multiple service types, is thus more powerful and in turn is used more often.
I also find the signature StronglyTypedServiceConfigurator<TDependency, TInstance> As<TService>()
quite confusing on first sight. Why do I have two service types here (TDependency
and TService
) and how do they relate?
Delegate-based configuration can be hard to format
I find all code that uses WeaklyTypedServiceConfigurator
or StronglyTypedServiceConfigurator<TDependency, TInstance>
is hard to format in a clean way as it is primarily delegate based. Every registration is really just one big function call.
I am all for fluent design, but this makes it hard to mentally parse the code.
Proposal
The service configurators use the builder pattern anyway, so we reasonably can just pull that into the Register
method, which currently returns void
.
var builder = new ContainerBuilder();
builder.Register<Implementation>().As<IService>();
var singleton = new Singleton();
builder.Register<Singleton>()
.As<ISingleton>()
.As<ISecondaryInterface>()
.With(Lifetime.PerContainer)
.Inject(Expression.Constant(singleton));
from singularity.
Your proposal doesn't actually make it possible to add compile time checks when registering with multiple services.
Iam thinking to drop the As method completely and simply add some overloads with more generic parameters for the common use cases. This does mean there is going to be a maximum amount of service types for a given implementation. If really needed one could pass in a array of service types when using the weakly typed api but having a dependency with many service types is not really good design so its not a common use case.
from singularity.
Related Issues (20)
- Consider adding a AspNetCore.Hosting package for Singularity HOT 1
- Add a smart constructor selector HOT 1
- Add logging HOT 1
- Document what ServiceBindingGenerators are and what they can be used for
- Support injection via arrays HOT 2
- Make sure service binding generators don't use any internal API's
- Cannot add migration with EF HOT 3
- Make ServiceBinding immutable
- Stack overflow in worker service if ExecuteAsync throws an exception HOT 3
- Come up with a better name
- No way to remove type from ConstructorResolverCache HOT 8
- Fix the wrong build status being reported
- No way to remove type from RegistrationStore and _getInstanceCache HOT 5
- Double initialization when resolving strongly typed singleton registrations using concrete type HOT 7
- Null exception error HOT 2
- Split the IConstructorResolver interface
- GetInstance<T>() should return non-nullable T HOT 2
- Construction of service with unregistered interface as dependency fails silently when requested in a collection HOT 1
- Question about resolving
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from singularity.