Dependency Inversion Principle states that higher level modules should not depend on lower level modules. Both should depend on abstractions. I do understand that principle. But as I'm using ASP.NET MVC, I often get my controller methods as:
public ActionResult MyAction(string userValue)
{
User user = MyDatabase.GetUser();
if (!user.CheckSomeCondition(userValue))
{ //Something failed. Try again.
return View();
}
user.Update(userValue);
return RedirectToAction("Success");
}
I believe this violates DIP because the result of my controller depends on the User class. In this scenario, I cannot think of a way of decoupling the Controller from my User class. Is there a way to get rid of this dependency? Or is this just fine to do it this way in this scenario?
create an interface and inject an implementation on that to your mvc controller.
public interface IMyDataAccess
{
User GetUser();
}
Create your implementation now.
public class MyMongoDBDataAccess : IMyDataAccess
{
public User GetUser()
{
//return a user from my fancy db
}
}
Now in your controller
public class HomeController : Controller
{
IMyDataAccess dao;
public HomeController(IMyDataAccess myDataAccess)
{
this.dao=myDataAccess;
}
public ActionResult MyAction(string userValue)
{
User user=this.dao.GetUser();
//return something to the view as needed.
}
}
You may use any dependency injection framework like Unity to inject the desired implementation of your interface to your controller.
If you want bring in more layers like Business Layer, Service layer, follow the same thing.
If your application structure is like below, than you are implementing DIP (Dependency Inversion Principle).
DIP says that a layer in your application should depend on a interface, not by an implementation. Like below, Service is depending on IDatabase not MyDatabase
public interface IDatabase {
Update(User user);
}
public interface MyDatabase : IDatabase
{
public Update(User user) {
// update user
}
}
public interface IService {
Update(string user);
}
public class Service : IService
{
private IDatabase _database;
public Service(IDatabase database)
{
_database = database;
}
public Update(User user) {
_database.Update(user);
}
}
DIP also says that high level modules like MvcController don't need to know/depend on low level modules, MyDatabase.
public class MvcController : Controller
{
private IService _service;
private IUserValidator _userValidator;
public MvcController(IService service, IUserValidator userValidator) // depending on abstraction
{
_service = service;
_userValidator = userValidator;
}
public ActionResult MyAction(string userValue)
{
if (!_userValidator.CheckSomeCondition(userValue))
{ //Something failed. Try again.
return View();
}
User user = _service.GetUser();
user.UserValue = userValue;
_service.Update(user);
return RedirectToAction("Success");
}
}
Note:
I recommend to take a look on 3-tier-architecture doing this you will improve your understanding of SOLID and your application will be more organized.
If in your case MyDatabase is a module Higher then User than, you are not respecting DIP principles, because your Controller make uses of a lower module.
DIP or IoC says High-level modules should not depend on low-level modules. Both should depend on abstractions.
It means that High Level class should not depend on concrete class but it should depend on Interface.
But here you are talking about User class which seems a DTO (Data Transfer Object).
So In that case, You must have to use that DTO in your last layer to either return data or deal with data.
But you should not be using POCO classes provided by entity framework, Instead you should create and use your DTO classes as ViewModels.
Ups, this is how I do it when using ASP.NET Web API, not sure if this works MVC Controller. But there is Unity.MVC (v3 or v4 or v5) lib (Unity.Mvc4) that you can use!
And you can wire it up like this, you should call this code in the Application_Start event!
public static class WebApiBootstrapper
{
public static void Init(IUnityContainer container)
{
GlobalConfiguration.Configure(config =>
{
config.DependencyResolver = new WebApiDependencyResolver(container); // DI container for use in WebApi
config.MapHttpAttributeRoutes();
WebApiRouteConfig.RegisterRoutes(RouteTable.Routes);
});
// Web API mappings
// All components that implement IDisposable should be
// registered with the HierarchicalLifetimeManager to ensure that they are properly disposed at the end of the request.
container.RegisterType<IYourController, YourController>(
new HierarchicalLifetimeManager(), new InjectionConstructor(typeof(IMyDataBase)));
}
}
But before running tthis code you have to register the type mapping
container.RegisterType<IMyDatabse, MyDataBase>();
And you also have to implement the DependencyResolver class:
public class WebApiDependencyResolver : IDependencyResolver
{
protected IUnityContainer container;
public WebApiDependencyResolver(IUnityContainer container)
{
if (container == null)
{
throw new ArgumentNullException("container");
}
this.container = container;
}
public object GetService(Type serviceType)
{
try
{
return container.Resolve(serviceType);
}
catch (ResolutionFailedException)
{
return null;
}
}
public IEnumerable<object> GetServices(Type serviceType)
{
try
{
return container.ResolveAll(serviceType);
}
catch (ResolutionFailedException)
{
return new List<object>();
}
}
public IDependencyScope BeginScope()
{
var child = container.CreateChildContainer();
return new WebApiDependencyResolver(child);
}
public void Dispose()
{
container.Dispose();
}
}
In your controller:
public class YourController : ApiController, IYourController
{
IDataBase _db;
public PlayGroundController(IDataBase db)
{
_db = db;
}
Related
I migrate my ASP.NET multi layer project to ASP.NET Core. I was using Ninject for DI in my old project and i could call it as follow in my BLL.
public void IamMethodInBll()
{
...
//i could call ninject like this.
var prodCalcManager = Const.NinjectKernel.Get<IProdCalcService>();
prodSurr.CalculatedPrice = prodCalcManager.GetMyMethod()
..
}
In now i use ASP Net Core's DI system of course. But how can i call the service locator in business layer for ASP.NET core? I need your samples and suggestions.
In Startup.cs
services.AddScoped<IProdCalcService,ProdCalcManager>();
In BLL
public void IamMethodInBll()
{
...
//What's the proper way to call another service in BLL
//How can i get the service provider in BLL
var prodCalcManager = _serviceProvider.GetService<IProdCalcService>();
prodSurr.CalculatedPrice = prodCalcManager.GetMyMethod()
..
}
The correct answer is: Dont use ServiceLocator. Register your services using the services.AddScoped<T> like you are and then add that to the constructor of the class you want to use it in.
Like so:
services.AddScoped<IProdCalcService,ProdCalcManager>();
Then your class looks like this:
public class MyClass()
{
private IProdCalcService calcService;
public MyClass(IProdCalcService calcService)
{
this.calcService = calcService;
}
public void IamMethodInBll()
{
//...
prodSurr.CalculatedPrice = calcService.GetMyMethod();
//...
}
}
It is better to DONT USE Service Locator but in this case you can inject ServiceProvider to your Controller or better solution is wrap and abstract ServiceProvider in a Container that can be injectable simply.
I prefer to use 3rd party DI Containers for use in this situation, specially CastleCore can be good choice.
public interface IContainer
{
T Resolve<T>();
}
public class ServiceProviderContainer : IContainer
{
private IServiceProvider _serviceProvider;
public ServiceProviderContainer(IServiceProvider serviceProvider)
{
this._serivceProvider = serviceProvider;
}
public T Resolve<T>()
{
return _seriveProvider.GetService<T>();
}
}
public class MyController : Controller
{
private IContainer contianer;
public MyController(IContainer container)
{
this._container = container;
}
public IActionResult Get()
{
var service = _container.Resolve<IUserRepository>();
}
}
Long story short, this is the type of controllers that i see in every code base professionally:
//All in One Service interfaces
public class DiController : ControllerBase
{
private readonly IDiService _diService;
public DiController(IDiService diService)
{
_diService = diService;
}
[HttpGet]
public IActionResult GetA()
{
return Ok(_diService.GetA());
}
[HttpGet]
public IActionResult GetB()
{
return Ok(_diService.GetB());
}
}
//Task-based interfaces
public class DiController : ControllerBase
{
private readonly IAService _aService;
private readonly IBService _bService;
public DiController(IAService aService, IBService bService)
{
_aService = aService;
_bService = bService;
}
[HttpGet]
public IActionResult GetA()
{
return Ok(_aService.Handle());
}
[HttpGet]
public IActionResult GetB()
{
return Ok(_bService.Handle());
}
}
Now to keep the post small, imagine that you have one repository for A and other for B, to be used by the service(s). Every component here is Scoped (the same object for every request). Don´t matter what you choose, you end up with a situation like this:
This is in the case of the Task-based interface, and as you can see, you are not using the service B but you get one instance regardless. In the other case you will have the two repositories instantiated.
To solve this problem i used Factories like this:
1 - An abstract class that holds the container and a property that supplies an instance of the Type.
public interface IGenericFactory<out T>
{
T Service { get; }
}
public abstract class GenericFactory<T> : IGenericFactory<T> where T : class
{
private readonly Container _container;
public T Service => _container.GetInstance<T>();
protected GenericFactory(Container container)
{
_container = container;
}
}
2- The interface to be registered in the container
public interface IAServiceFactory : IGenericFactory<IAService>
{
}
3- The class to be registered in the container
public class AServiceFactory : GenericFactory<IAService>, IAServiceFactory
{
public AServiceFactory(Container container) : base(container)
{
}
}
4- Register the factories as Singletons and the services as Scoped/Transient (according to the use case). This would be an example (in Simple Injector) of how the registration for the Task-Based Interface Controller is done:
_container.Register<IAService, AService>(Lifestyle.Scoped);
_container.Register<IBService, BService>(Lifestyle.Scoped);
_container.Register<IAServiceFactory, AServiceFactory>(Lifestyle.Singleton);
_container.Register<IBServiceFactory, BServiceFactory>(Lifestyle.Singleton);
The final product will be this:
An instance of A, and no B.
Is this correct? I have been in projects where you would have a dozen of Services or Repositories, and only one would be used in each call.
Thank you.
You can inject into the action:
public IActionResult About([FromServices] IDateTime dateTime)
{
ViewData["Message"] = $"Current server time: {dateTime.Now}";
return View();
}
https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/dependency-injection?view=aspnetcore-2.2#action-injection-with-fromservices
Is it good to resolve the dependencies dynamically like the way i'm doing. Everywhere, it is suggested to use Constructor injection. I really don't understand the drawbacks of doing it the way i'm doing it. Code snippets as below..
Employee.cs
public class Employee
{
public int Id { get; set; }
public string Name { get; set; }
public int Age { get; set; }
public Department Department { get; set; }
}
IRepository.cs
public interface IRepository<TModel> where TModel : class
{
void Add();
IEnumerable<TModel> GetAll();
IEnumerable<TModel> GetByID();
}
Repository.cs
public class Repository<TModel> : IRepository<TModel> where TModel : class
{
public void Add()
{
throw new NotImplementedException();
}
public IEnumerable<TModel> GetAll()
{
throw new NotImplementedException();
}
public IEnumerable<TModel> GetByID()
{
throw new NotImplementedException();
}
}
EmployeeController.cs
public class HomeController : ApiController
{
IComponentContext _container;
public HomeController(IComponentContext container)
{
this._container = container;
}
public Repository<TModel> Using<TModel>() where TModel :class
{
var repository = _container.Resolve(typeof(IRepository<TModel>));
return repository as Repository<TModel>;
}
[HttpGet]
public IEnumerable<Employee> GetEmployees()
{
return Using<Employee>().GetAll();
}
}
Global.asax
protected void Application_Start()
{
GlobalConfiguration.Configure(WebApiConfig.Register);
var builder = new ContainerBuilder();
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
builder.RegisterGeneric(typeof(Repository<>)).As(typeof(IRepository<>));
var container = builder.Build(Autofac.Builder.ContainerBuildOptions.None);
var webApiResolver = new AutofacWebApiDependencyResolver(container);
GlobalConfiguration.Configuration.DependencyResolver = webApiResolver;
}
Say i've 5 repositories, Constructor injection will resolve all the 5 dependencies for a request i make. I might not use 5 repositories for each and every request. SO i thought of resolving dependencies dynamically by passing the type like i'm doing it in Using<TModel>(). Any suggestions would be appreciated..!! Thank you...!!
Refrain from using the container directly inside your application components; this leads to all kinds of troubles such as maintainability and testability issues. Directly resolving instances from within application code is a well-known anti-pattern known as Service Locator.
As a first refactoring, you can instead apply the Unit of Work pattern. A Unit of Work allows access to underlying repositories. For instance:
public interface IUnitOfWork
{
IRepository<TModel> Repository<TModel>();
}
public sealed class HomeController : ApiController
{
private readonly IUnitOfWork _unitOfWork;
public HomeController(IUnitOfWork unitOfWork)
{
this._unitOfWork = unitOfWork;
}
[HttpGet]
public IEnumerable<Employee> GetEmployees()
{
return this._unitOfWork.Repository<Employee>().GetAll();
}
}
Within the Composition Root (where it is allowed to access the container), we can now create an IUnitOfWork implementation that resolves repositories dynamically:
private sealed class AutofacUnitOfWork : IUnitOfWork
{
private readonly IComponentContext _container;
public AutofacUnitOfWork(IComponentContext container)
{
this._container = container;
}
public IRepository<TModel> Repository<TModel>()
{
return _container.Resolve<IRepository<TModel>>();
}
}
This pattern simplifies your application components considerably and prevents downsides that the Service Locator anti-pattern typically causes.
Although applying the Unit of Work pattern might be a useful step into the right direction, an even better approach is to skip the Unit of Work directly and simply inject a required repository directly into application components:
public sealed class HomeController : ApiController
{
private readonly IRepository<Employee> _employeeRepository;
public HomeController(IRepository<Employee> employeeRepository)
{
this._employeeRepository = employeeRepository;
}
[HttpGet]
public IEnumerable<Employee> GetEmployees()
{
return this._employeeRepository.GetAll();
}
}
Say i've 5 repositories, Constructor injection will resolve all the 5 dependencies for a request i make. I might not use 5 repositories for each and every request.
Note that from a performance perspective, you should typically not be concerned whether dependencies are used or not. Autofac is in most cases fast enough and it is unlikely that this will actually cause any performance problems in your production systems.
From a design perspective however you should be more worried if a class has many dependencies, while methods just use a few of them. This means that the methods in the class have little cohesion. This is an indication that the class should be split up into multiple smaller classes; it has multiple responsibilities.
I have a service defined like this:
public class MentorService : IMentorService
{
private readonly Func<MentorContext> _dbFactory;
public MentorService(string connectionString)
{
this._dbFactory = () => new MentorContext(connectionString);
}
public MentorService()
{
this._dbFactory = () => new MentorContext();
}
public MentorContext CreateContext()
{
return _dbFactory.Invoke();
}
public IList<User> GetUsers()
{
using (var db = CreateContext())
{
return db.Users.ToList();
}
}
// etc etc
}
Within my API controllers, I have the following:
public class UserController : ApiController
{
private readonly IMentorService _mentorService;
public UserController()
{
_mentorService = new MentorService();
}
public UserController(IMentorService mentorService)
{
_mentorService = mentorService;
}
}
I'd like to break the service up into sub-services for easier maintenance and testing - something like UserService, BookService, etc. Then I just want to use a single service in my controllers.
How can this be done?
I am a huge fan of factories for this sort of thing.
(Please note, I am assuming you have some sort of DI/IoC setup, considering you have an interface-based example)
Basically, you first split your code into separate classes UserService, BookService, etc. Once you've done that, you create a factory that creates these services for you. Something like this:
public class UserControllerServiceFactory : IUserControllerServiceFactory {
public IUserService CreateUserService() {
return _container.Get<IUserService>();
}
public IBookService CreateBookService() {
return _container.Get<IBookService>();
}
// etc.
}
We use Ninject for our DI/IoC, and prefer to use the Factories extensions for Ninject. This means we don't have to implement the factories ourselves.. we only define the interfaces.
Then you have the factory injected into your controller:
public UserController(IUserControllerServiceFactory factory) {
_factory = factory;
}
And then, your Action Methods use the factory to access the services you require:
[HttpGet]
public ActionResult ViewAllBooks() {
return View(_factory.CreateBookService().GetAll());
}
etc.
I hope that is what you meant.
I heared this should be possible, but I can not imagine how this should work.
I am using Dependency Injection (autofac) for my project. I develop a project with someone else and call the methods of his classes (I use his assembly).
Then I get an instance of an object which the other person should use for his operations.
We want to avoid passing this object instance on every method and use autofac.
Can he resolve this instance in his assembly project without passing any parameter?
I think we have to pass at least the DI-Container... But I heard that the concept of Dependency Injection should make it possible that you can resolve objects in the whole "execution context" and get the same one.
Here is an example with the asp.net web api:
This is a api controller of a asp.net webapi project:
public class DocumentsController : ApiController
{
// GET /api/documents
public HttpResponseMessage Get()
{
// Here I call the method of the other developer,
// security/authorization should be handled in
// his method!
// In this context the WebAPI provides the
// IPrincipal of the current user in this
// variable => "HttpContext.Current.User" but we
// don't want to pass it on every method call
ClassFromOtherAssembly.GetDocuments();
HttpResponseMessage response =
Request.CreateResponse<IEnumerable<Document>>(
HttpStatusCode.OK, documents);
return response;
}
}
This is the class of the other developer. He should deliver the documents and check if the user is authorized:
public class ClassFromOtherAssembly
{
public List<Documents> GetDocuments()
{
//Security check
IPrincipal principal =
DI_Container.Resolve(IPrincipal);
if(principal.IsInRole("Admin"))
{
//return the list
}
else
{
//return empty list
}
}
}
No, do not pass the container itself, you will end up with a Service Locator patter, and if you do a quick search you will understand that this pattern has a rotten smell.
public class Foo
{
private IContainer container;
private IBar bar;
public Foo( IContainer container) //no-no
{
this.container = container;
this.bar = container.Resolve<IBar>();
}
}
Instead use proper DI, like
public class Foo
{
private IBar bar;
public Foo(IBar bar)
{
this.bar = bar;
}
}
It doesn't really matter in which assembly your types are. This is the whole point of IoC and DI - to decouple parts of the application and make you depend on abstractions, rather than concrete implementations.
Edit
You misunderstood Service locator pattern with DI. "Instead of passing a parameter we want to use Dependency Injection" - passing a parameter is a DI, in contrast, resolving a type from a static container is a service locator.
public class DocumentsController : ApiController
{
public HttpResponseMessage Get()
{
ClassFromOtherAssembly.GetDocuments(); //this is Service locator
//really bad for testability and maintenance
...
}
}
DI looks like this
public class DocumentsController : ApiController
{
private IDocumentProvider;
public DocumentsController(IDocumentProvider provider)
{
this.provider = provider;
}
public HttpResponseMessage Get()
{
provider.GetDocuments(); //this is DI
...
}
}
You're using the ServiceLocator (anti-pattern) by calling Resolve directly from GetDocuments()
Use inversion of control with constructor injection to pass in the IPrinciple thus:
public class ClassFromOtherAssembly
{
private IPrincipal principal;
public ClassFromOtherAssembly(IPrincipal principal)
{
this.principal = principal;
}
public List<Documents> GetDocuments()
{
//Security check
if (principal.IsInRole("Admin"))
{
//return the list
}
else
{
//return empty list
}
}
}