I have lack of understanding in this basic concept of OOP. Here is an example:
Say I have a base repository which is derived by 3 different classes. The base class requires the dbContext in the constructor , injected by dependency injection. Because of this the child classes have to pass the dbContext every time I instantiate them. The requirement is simple: The base class should instantiate the Context for the child classes. Is that possible? I do not want the child classes to worry about the context. I just want them to call it.
Here is my base class.
public class CastingBaseRepository<TEntity> : ICastingBaseRepository<TEntity> where TEntity : class, IEntity
{
private readonly CastingContext _context;
public CastingBaseRepository(CastingContext context) => _context = context ?? throw new ArgumentNullException(nameof(context));
// Context property
public CastingContext Context => _context;
}
Heres how the child class would be:
public class CommercialJobsRepository : CastingBaseRepository<Audition>, ICommercialJobsRepository
{
/* I do not want to use base(context) here. I need a way for this class to just call Context property from the derived class.. Possible? */
private CastingContext _context;
public CommercialJobsRepository(CastingContext context) : base(context)
{
_context = context;
}
public async Task<IList<OpenJobs>> GetOpenJobs()
{
// test code
var tt = await _context.Audition.Take(10).ToListAsync();
return new List<OpenJobs>();
}
}
Here is my context class
public partial class CastingContext : DbContext
{
public virtual DbSet<Audition> Audition { get; set; }
public CastingContext(DbContextOptions<CastingContext> options) : base(options)
{
}
}
And here is the startup.cs
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// DB Context
services.AddDbContextPool<CastingContext>(options => { options.EnableSensitiveDataLogging(); options.UseSqlServer(Configuration.GetConnectionString("dbCast")); });
}
}
I am using strategy pattern to determine which child class would be accessed at runtime. That too needs to have CastingContext injected the constructor which is again ugly. The point is, there should be only one class exposing the context to all derived classes or perhaps through a static method. Can you please help me understand how to do it?
Here is my Strategy class:
public class JobsStrategyContext
{
private readonly CastingContext _context;
private readonly Dictionary<eBreakdownTypes, IJobsRepository> Strategies =
new Dictionary<eBreakdownTypes, IJobsRepository>();
public JobsStrategyContext(CastingContext context)
{
_context = context;
Strategies.Add(eBreakdownTypes.Ftv, new FtvJobsRepository(_context));
Strategies.Add(eBreakdownTypes.Commercial, new CommercialJobsRepository(_context));
Strategies.Add(eBreakdownTypes.Theatre, new TheatreJobsRepository(_context));
}
public async Task<IList<OpenJobs>> GetOpenJobsBySubType(eBreakdownTypes breakdownType)
{
return await Strategies[breakdownType].GetOpenJobs();
}
}
No, you cannot both at the same time use dependency injection and hardcode the instantiation of your dependency in the base class. If you want to inject the dependency from an external consumer, it needs to pass through the derived constructor.
At best, you can pass a service locator which the base constructor then uses to fetch the dbcontext, but then you're still handling the service locator in the derived class. But service locators are no longer considered good practice because they have notable drawbacks such as decreasing readability/usability and becoming a general nuisance to handle in sufficiently large codebases.
While it would technically achieve what you want to achieve, don't start using static service locators. The costs far outweigh the benefits.
However, the problem outset doesn't quite make sense to me. If you're using dependency injection, I would assume you're using some sort of automated injection where you don't have to manually instantiate all dependencies.
Yes, you still need to mention the dbcontext as a (derived and base) constructor parameter, but your derived classes don't need to handle it (other than passing it to the base constructor. The effort to do so is minimal and it allows for maximum freedom in terms of dependency injection.
This is how inheritance works by design.
This is a functional limitation of C# as a language. You don't have to provide the same constructor(s) in child classes as you have in the base class, but you must satisfy those constructors in the base class. For example:
public class BaseClass
{
public BaseClass(Dependency dep) {}
}
public class ChildClass
{
public ChildClass(Dependency dep) : base(dep) {}
}
Or:
public class ChildClass
{
public ChildClass() : base(new Dependency()) {}
}
In either case, you somehow, someway must provide the Dependency instance to the base class constructor, but you may opt to not actually construct the child class with that dependency, and instead, get it internally.
However, in practical terms with something like DbContext which relies itself on dependencies being injected, it's going to require carrying that dependency all the way through: your child class will need a constructor where it can be injected in order to then pass down into the base class constructor.
You have to provide the dependency through the child class because, When you are creating an instance of the child class, the base class is also getting constructed and hence the dependencies must be supplied.
Of course for the ease of coding and managing these dependencies,you can use Use the IoC containers like Unity to handle the automatic dependency injections (The Unity Application dependency injection container with support for constructor, property, and method call injection)
Related
In my startup.cs I have code like this
services.AddScoped<IFileStorage, DiskFileStorage>();
service.Add<IImageHandler, ImageHandler>();
public class ImageHandler
{
ImageHandler(IFileStorage fileStorage, ...){}
}
now I want to add another class, OtherHandler, that takes a IFileStorage interface, but with another implementation, something like this
services.AddScoped<IFileStorage, NetworkFileStorage>();
public class OtherHandler:IOtherHandler
{
OtherHandler(IFileStorage, fileStorage)
}
Now how do i configure stuff so that the OtherHandler would use the NetworkFileStorage implementation for IFileStorage and anything else would use a default DiskFileStorage implementation?
Update:
Thanks to gunr2171 comment, I discovered that I could do a
services.AddScoped<IOtherHandler>(provider => new OtherHandler(provider.GetRequiredService<NetworkFileStorage>())); to get a specific implementation. But still curious if it is possible if I for some reason wanted to use an interface.
So, based on my understanding this is your scenario:
public interface IFileStorage
{
}
public class NetworkFileStorage: IFileStorage
{
}
public class DiskFileStorage: IFileStorage
{
}
You also have a couple of services depending on the IFileStorage service:
public class ImageHandler: IImageHandler
{
public ImageHandler(IFileStorage fileStorage)
{
}
}
public class OtherHandler: IOtherHandler
{
public OtherHandler(IFileStorage fileStorage)
{
}
}
You want to register your services so that both of the followings hold true:
instances of ImageHandler are built by injecting NetworkFileStorage
instances of OtherHandler are built by injecting DiskFileStorage
For simplicity, I'll suppose that all the involved types are implemented so that it is ok to register them as singletons. This depends on the actual implementation, in any case the pattern that I'm going to show you doesn't depend on the actual lifetime of the involved types.
First of all, register the concrete implementations of the IFileStorage interface. You need to register the classes (not the interface): the purpose of this is making sure that the DI container knows these types and it is able to provide you instances of both types.
services.AddSingleton<NetworkFileStorage>();
services.AddSingleton<DiskFileStorage>();
Now, you can register an implementation for the IImageHandler service.
You will use the ImageHandler class as the implementing type and you will also provide a factory method to the DI container: by doing so, you are able to select the implementation of IFileStorage to be injected (in this case you will select the NetworkFileStorage type).
services.AddSingleton<IImageHandler>(sp =>
{
var fileStorage = sp.GetRequiredService<NetworkFileStorage>();
return ActivatorUtilities.CreateInstance<ImageHandler>(sp, fileStorage);
});
You can do a similar thing to register the OtherHandler class as the implementation for the IOtherHandler service, and select the class DiskFileStorage as the type being injected in the constructor of OtherHandler:
services.AddSingleton<IOtherHandler>(sp =>
{
var fileStorage = sp.GetRequiredService<DiskFileStorage>();
return ActivatorUtilities.CreateInstance<OtherHandler>(sp, fileStorage);
});
Let me add a final note on your design. There is something wrong with it.
It seems to me that the ImageHandler class is somewhat strongly coupled with the NetworkFileStorage class, while the OtherHandler class is somewhat strongly coupled with the DiskFileStorage class.
I would expect both of these classes to work fine with any implementation of the IFileStorage interface. If these classes do really depend only on the behavior described by the IFileStorage interface, then any actual implementation of that behavior should be fine for them to work as expected. This is basically a violation of the Liskov Substitution Principle.
If this is not the case, maybe the interface IFileStorage is not a useful abstraction for your domain model and you should considered to redesign it or to define two different interfaces (one suited to the needs of the ImageHandler class and the other suited to the needs of the OtherHandler class).
I think there might be a more flexible approach here. It uses Adapter pattern for your services, allowing you to stay away from registering concrete implementations, and doesn't force you to instantiate every type manually that uses some FileStorage implementation.
// A generic storage that can be used for any scenario
public interface IFileStorage<T> where T : IFileAdapter
{
protected T Adapter { get; }
Task Handle();
}
// a base interface that defines the shape of adapter
public interface IFileAdapter
{
Task Handle();
}
// copy interfaces to separate the services
public interface ILocalFileAdapter : IFileAdapter
{
}
public interface IRemoteFileAdapter : IFileAdapter
{
}
// specific implementations
public class RemoteFileAdapter : IRemoteFileAdapter
{
private readonly ILogger<RemoteFileAdapter> logger;
public RemoteFileAdapter(ILogger<RemoteFileAdapter> logger)
{
this.logger = logger;
}
public Task Handle()
{
this.logger.LogWarning("Handling file remotely");
return Task.CompletedTask;
}
}
public class LocalFileAdapter : ILocalFileAdapter
{
private readonly ILogger<LocalFileAdapter> logger;
public LocalFileAdapter(ILogger<LocalFileAdapter> logger)
{
this.logger = logger;
}
public Task Handle()
{
this.logger.LogWarning("Handling file locally");
return Task.CompletedTask;
}
}
// generic storage that uses an adapter to handle the scenario
public class FileStorage<T> : IFileStorage<T> where T : IFileAdapter
{
public FileStorage(T fileAdapter)
{
Adapter = fileAdapter;
}
public T Adapter { get; }
public Task Handle()
{
return this.Adapter.Handle();
}
}
Register your services like below :
builder.Services.AddSingleton<ILocalFileAdapter, LocalFileAdapter>();
builder.Services.AddSingleton<IRemoteFileAdapter, RemoteFileAdapter>();
// aspnet.core allows you to register generic services
builder.Services.AddSingleton(typeof(IFileStorage<>), typeof(FileStorage<>));
And this is how you use your IFileStorageService:
public WeatherForecastController(IFileStorage<ILocalFileAdapter> localFileStorage, IFileStorage<IRemoteFileAdapter> remoteFileStorage)
{
localFileStorage.Handle();
remoteFileStorage.Handle();
}
// which will log :
// Handling file locally
// Handling file remotely
Let's say in C# I have a class called A
public class A : IInterfaceA
{
[Dependency]
B _b;
}
Then in B class I have a constructor like this:
public class B
{
...
public B(string someParam) { ... }
...
}
Now, I register class A like this:
_unityContainer.RegisterType<IInterfaceA, A>("RegistrationA");
and to resolve the interface I do:
_unityContainer.Resolve<IInterfaceA>("RegistrationA", new ParameterOverride("someParam", "The param."));
Now I want to know if it is good practice to resolve the class and pass the parameters like this or I should do it another way.
Thanks a lot :)
First of all the code you posted does not work: in fact you're overriding the parameter of class A, while in your code the constructor with the parameter is B.
Generally speaking, using parameter override is not a good practice in my opinion (unless some very specifical context like a console application or a web service using an existing container but it's avoidable in most cases) for these reason:
Using Resolve looks like a Service locator: anti-pattern nowadays. You will find a lot of discussion googling about.
Using ParameterOverride means that the client (the caller of Resolve) knows exactly the type mapped in the container and wants that type initialized with a specific parameter. But this is just the opposite of inversion of control.
The best way is to use an abstract factory. You can add in your code and use a more flexible and SOLID abstract factory:
public interface BFactory {
B Create(string bparam);
}
public class BFactoryUnity : BFactory {
private IUnityContainer container;
public BFactoryUnity(IUnityContainer container) {
this.container = container;
}
public B Create(String bParam) {
var b = new B(bParam);
container.BuildUp(b);
return b;
}
}
So you can register:
_unityContainer.RegisterType<IInterfaceA, A>("RegistrationA")
.RegisterType<BFactory, BFactoryUnity>();
Now the client can resolve only the factory and use it:
var bFactory = _container.Resolve<BFactory>();
var b = bFactory.Create();
Now, in a big application you will need a lot of similar factories. To avoid the boilerplate code of abstract factories and implementations you can find in the web some implementation of automatic abstract factory extensions.
I am trying to use property injection for StructureMap in a plug-in style system.
ObjectFactory.Initialize(o => o.Scan(s =>
{
s.AssembliesFromPath("path_to_assemblies");
s.WithDefaultConventions();
});
Here is a sample implementation (purposely did not go deeper in defining T and TU as they are just simple classes)
public interface IBarService
{
void Baz();
}
public class BarService : IBarService
{
public void Baz() { /* implementation */ }
}
public abstract class PluginBase<T, TU> : IPlugin
where T : AClass, new()
where TU : BClass
{
protected PluginBase()
{
//some init code in the constructor
}
}
//Foo is created at run-time via Activator.CreateInstance()
public class FooPlugin : PluginBase<AClass, BClass>
{
[SetterProperty]
public IBarService BarService { get; set; }
public void Fooey()
{
BarService.Baz();
}
}
I want to auto-wire the property dependencies on all of these plug-ins that are created at run-time. I thought I'd start out with property injection and then move things to the constructor if the need arose.
If I do:
var obj = ObjectFactory.GetInstance<IBarService>();
anywhere in an instance of FooPlugin, I get the correct implementation and all is well.
If I do:
this.BarService.Baz();
I get a null reference exception because no instance of IBarService was set.
After I create my plug-in, if I do this:
ObjectFactory.BuildUp(pluginObject).
All is well and FooPlugin has the correct implementation of IBarService.
Is there any way to simply allow me to decorate my plugin properties with [SetterProperty] and have StructureMap automatically inject those when the Plugin is created without having to call ObjectFactory.BuildUp(pluginObject) ?
How are you creating your plugin instance in the cases where it doesn't work? Are you just doing new FooPlugin()?
If you do var plugin = ObjectFactory.GetInstance<PluginBase<AClass, BClass>>();, do you get the plugin with all the correct dependencies resolved?
If you are instantiating the object with "new", the container has no way to know that the instance needs dependencies resolved--it has no knowledge of that instance. Instances that need injected dependencies must be "managed by the container" so to speak.
You'll save yourself a lot of trouble if you just go the opposite route and inject all dependencies in the contstructor(s). This way there is a single place where you need to check if your objects are initialized properly...
I have a series of classes each with several dependencies according to their role. These dependencies are being injected into the constructor. An example would be:
public class UserViewModel
{
//...
public UserViewModel(IDataService dataService,
INotificationService notificationService,
IDialogService dialogService,
INavigationService navigationService)
{
this.DataService = dataService;
this.NotificationService = notificationService;
this.DialogService = dialogService;
this.NavigationService = navigationService;
}
}
As you can see, there are several arguments to set. I could write an interface like the following:
public interface IInteractionService
{
public INotificationService NotificationService { get; set; }
public IDialogService DialogService { get; set; }
public INavigationService { get; set; }
}
and pass the injected InteractionService implementation to the UserViewModel's constructor in one piece:
public UserViewModel(IDataService dataService,
IInteractionService interactionService) {}
and use it like:
this.InteractionService.NotificationService.Publish(message);
Are there any issues with using an interaction interface holding interface properties in terms of design patterns/principles? Or is there a better way to look at it?
Thanks for any advice...
In general, you should not create "God" service with different services inside. It breaks Single Response Principle (SRP).
But I do not understand how it can be that DI injects you null against instance of service? May be you should fix this behaviour against creating "God" service?
IMO, dependency injection in a constructor is a way to hell. Could you predict the final number of dependencies during the lifetime of your application? Do you really want to modify ctor's code everytime? Do you really want to initialize all dependencies at once, instead of lazy initialization?
MEF, e.g., can inject private fields in lazy manner.
You definitely shouldn't test for null injected values. If your DI-framework doesn't make these tests itself, then throw it away and use normal one.
I currently have a main class which might call another class which might call 2 or 3 others. The main class might create a Windows form as well.
So at the moment we might have:
public class MainClass
{
...
AnotherClass = new AnotherClass();
fmMain myForm = new fmMain();
}
public class AnotherClass
{
...
DatabaseClass dbClass = new DatabaseClass();
FileClass fClass = new FileClass();
}
As I see it, after refactoring and putting in constructor interface dependencies I can use an IOC container.
The problem is my entry point is the main class so all I can see to do is have all the dependencies in the main class constructor and then pass these down into the other classes and forms.
The issue is this could get very messy and the main class might have 10 dependencies most of which used in other classes. Is there an alternative?
Let the IoC container to do this.
Register AnotherClass as a dependency and then resolve it directly referring to container instance.
Dependencies should be defined locally to where they are required i.e. the dependencies should be defined on the constructors of the types, then use an IoC container to resolve all types. In this way the IoC takes care of "passing these down into the other classes and forms". When using an IoC container avoid using "new" whenever possible, and instead use the container to create instances. It will handle creation and injection of dependencies for you.
For example (using Ninject), the following demonstrates a Form which defines its own dependencies. The container will supply and inject all dependencies recursively when used to resolve an instance of the ProductForm.
Dependencies do not need to be injected into the entry-point class, but are specified as bindings in a module and then injected by the container when types such as Forms are resolved.
public class Program
{
public Program()
{
IKernel kernel = new StandardKernel(new MainModule());
Form form = kernel.Get<ProductForm>();
form.Show();
}
}
public class MainModule : NinjectModule
{
public override void Load()
{
Bind<ProductForm>().ToSelf();
Bind<IProductService>().To<ProductService>();
Bind<IProductDb>().To<IProductDb>();
}
}
internal class ProductForm : Form
{
private readonly IProductService _productService;
public ProductForm(IProductService productService)
{
_productService = productService;
}
}
internal interface IProductService {}
internal class ProductService : IProductService
{
private readonly IProductDb _productDb;
public ProductService(IProductDb productDb)
{
_productDb = productDb;
}
}
internal interface IProductDb {}
internal class ProductDb : IProductDb {}
It sounds like your Main class is your Composition Root. That's fine - it's not going to become messy if that's the only thing it does. This should be its single responsibility. In other words: your application entry point should be a Humble Object.