Property / method injection using Autofac in filter attributes












2















Trying to use autofac for dependency injection by property.



The instance is always null and there is no dependency injected.
Below is class where the property needs to be injected.



public class UserAccount
{
public IAccountService AccountService { get; set; }

public string Message()
{
return AccountService.Message();
}
}


I have tried three different ways to inject the property but none was successful



Method 1 :



builder.Register(c => {
var result = new UserAccount();
var dep = c.Resolve<IAccountService>();
result.SetDependency(dep);
return result;
});


Method 2 :



builder.RegisterType<UserAccount>().PropertiesAutowired();


Method 3 :



builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


PS : Method injection of above is welcomed.










share|improve this question

























  • Is the UserAccount object created by Autofac, too? If you create it manually (by using the new operator), it will not work, because Autofac is not involved in the object creation.

    – KBO
    Nov 22 '18 at 7:44











  • @KBO yes i am manually creating it using new, what should i do then ?

    – Matt Burner
    Nov 22 '18 at 8:10











  • Please show the code that shows how you resolve and use UserAccount.

    – Steven
    Nov 22 '18 at 8:49











  • Possible duplicate of: stackoverflow.com/questions/29915192/…

    – Steven
    Nov 22 '18 at 10:02











  • Where's the filter attribute mentioned in the question title? What framework is the filter attribute?

    – Travis Illig
    Nov 22 '18 at 19:34
















2















Trying to use autofac for dependency injection by property.



The instance is always null and there is no dependency injected.
Below is class where the property needs to be injected.



public class UserAccount
{
public IAccountService AccountService { get; set; }

public string Message()
{
return AccountService.Message();
}
}


I have tried three different ways to inject the property but none was successful



Method 1 :



builder.Register(c => {
var result = new UserAccount();
var dep = c.Resolve<IAccountService>();
result.SetDependency(dep);
return result;
});


Method 2 :



builder.RegisterType<UserAccount>().PropertiesAutowired();


Method 3 :



builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


PS : Method injection of above is welcomed.










share|improve this question

























  • Is the UserAccount object created by Autofac, too? If you create it manually (by using the new operator), it will not work, because Autofac is not involved in the object creation.

    – KBO
    Nov 22 '18 at 7:44











  • @KBO yes i am manually creating it using new, what should i do then ?

    – Matt Burner
    Nov 22 '18 at 8:10











  • Please show the code that shows how you resolve and use UserAccount.

    – Steven
    Nov 22 '18 at 8:49











  • Possible duplicate of: stackoverflow.com/questions/29915192/…

    – Steven
    Nov 22 '18 at 10:02











  • Where's the filter attribute mentioned in the question title? What framework is the filter attribute?

    – Travis Illig
    Nov 22 '18 at 19:34














2












2








2








Trying to use autofac for dependency injection by property.



The instance is always null and there is no dependency injected.
Below is class where the property needs to be injected.



public class UserAccount
{
public IAccountService AccountService { get; set; }

public string Message()
{
return AccountService.Message();
}
}


I have tried three different ways to inject the property but none was successful



Method 1 :



builder.Register(c => {
var result = new UserAccount();
var dep = c.Resolve<IAccountService>();
result.SetDependency(dep);
return result;
});


Method 2 :



builder.RegisterType<UserAccount>().PropertiesAutowired();


Method 3 :



builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


PS : Method injection of above is welcomed.










share|improve this question
















Trying to use autofac for dependency injection by property.



The instance is always null and there is no dependency injected.
Below is class where the property needs to be injected.



public class UserAccount
{
public IAccountService AccountService { get; set; }

public string Message()
{
return AccountService.Message();
}
}


I have tried three different ways to inject the property but none was successful



Method 1 :



builder.Register(c => {
var result = new UserAccount();
var dep = c.Resolve<IAccountService>();
result.SetDependency(dep);
return result;
});


Method 2 :



builder.RegisterType<UserAccount>().PropertiesAutowired();


Method 3 :



builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


PS : Method injection of above is welcomed.







c# dependency-injection autofac property-injection






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 22 '18 at 10:50









Steven

127k17216334




127k17216334










asked Nov 22 '18 at 6:22









Matt BurnerMatt Burner

867




867













  • Is the UserAccount object created by Autofac, too? If you create it manually (by using the new operator), it will not work, because Autofac is not involved in the object creation.

    – KBO
    Nov 22 '18 at 7:44











  • @KBO yes i am manually creating it using new, what should i do then ?

    – Matt Burner
    Nov 22 '18 at 8:10











  • Please show the code that shows how you resolve and use UserAccount.

    – Steven
    Nov 22 '18 at 8:49











  • Possible duplicate of: stackoverflow.com/questions/29915192/…

    – Steven
    Nov 22 '18 at 10:02











  • Where's the filter attribute mentioned in the question title? What framework is the filter attribute?

    – Travis Illig
    Nov 22 '18 at 19:34



















  • Is the UserAccount object created by Autofac, too? If you create it manually (by using the new operator), it will not work, because Autofac is not involved in the object creation.

    – KBO
    Nov 22 '18 at 7:44











  • @KBO yes i am manually creating it using new, what should i do then ?

    – Matt Burner
    Nov 22 '18 at 8:10











  • Please show the code that shows how you resolve and use UserAccount.

    – Steven
    Nov 22 '18 at 8:49











  • Possible duplicate of: stackoverflow.com/questions/29915192/…

    – Steven
    Nov 22 '18 at 10:02











  • Where's the filter attribute mentioned in the question title? What framework is the filter attribute?

    – Travis Illig
    Nov 22 '18 at 19:34

















Is the UserAccount object created by Autofac, too? If you create it manually (by using the new operator), it will not work, because Autofac is not involved in the object creation.

– KBO
Nov 22 '18 at 7:44





Is the UserAccount object created by Autofac, too? If you create it manually (by using the new operator), it will not work, because Autofac is not involved in the object creation.

– KBO
Nov 22 '18 at 7:44













@KBO yes i am manually creating it using new, what should i do then ?

– Matt Burner
Nov 22 '18 at 8:10





@KBO yes i am manually creating it using new, what should i do then ?

– Matt Burner
Nov 22 '18 at 8:10













Please show the code that shows how you resolve and use UserAccount.

– Steven
Nov 22 '18 at 8:49





Please show the code that shows how you resolve and use UserAccount.

– Steven
Nov 22 '18 at 8:49













Possible duplicate of: stackoverflow.com/questions/29915192/…

– Steven
Nov 22 '18 at 10:02





Possible duplicate of: stackoverflow.com/questions/29915192/…

– Steven
Nov 22 '18 at 10:02













Where's the filter attribute mentioned in the question title? What framework is the filter attribute?

– Travis Illig
Nov 22 '18 at 19:34





Where's the filter attribute mentioned in the question title? What framework is the filter attribute?

– Travis Illig
Nov 22 '18 at 19:34












2 Answers
2






active

oldest

votes


















1














You should prevent letting your container create data-centric objects, such as your UserAccount entity. This leads to complicated scenarios, such as the one you are in now.



In general, your DI Container should resolve only components—those are the classes in your system that contain the application's behavior, without having any interesting state. Those types of classes are typically long lived, or at least. Data-centric objects, like entities, can best be created by hand. Not doing so would either lead to entities with big constructors, which easily causes the constructor over-injection code smell. As remedy, you might fall back on using Property Injection, but this causes a code smell of its own, caused Temporal Coupling.



Instead, a better solution is to:




  1. Create entities by hand, opposed to using a DI Container

  2. Supply dependencies to the entity using Method Injection, opposed to using Property Injection


With Method Injection, your UserAccount would as follows:



// This answer assumes that this class is an domain entity.
public class UserAccount
{
public Guid Id { get; set; }
public byte PasswordHash { get; set; }

public string Message(IAccountService accountService)
{
if (accountService == null) throw new ArgumentNullException(nameof(accountService));

return accountService.Message();
}
}


This does move the responsibility of supplying the dependency from the Composition Root to the entity's direct consumer, though. But as discussed above, this is intentional, as the Composition Root in general, and a DI Container in particular, should not be responsible of creating entities and other data-centric, short-lived objects.



This does mean, however, that UserAccount's direct consumer should inject that dependency, and with that, know about existence of the dependency. But as that consumer would be a behavior-centric class, the typical solution is to use Constructor Injection at that stage:



public class UserService : IUserService
{
private readonly IAccountService accountService;
private readonly IUserAccountRepository repo;

public UserService(IAccountService accountService, IUserAccountRepository repo)
{
this.accountService = accountService;
this.repo = repo
}

public void DoSomething(Guid id)
{
UserAccount entity = this.repo.GetById(id);
var message = entity.Message(this.accountService);
}
}





share|improve this answer


























  • But this would mean that i have to make a reference of the business layer in my presentation layer in order to access that repository... is that OK? I mean wouldn't that violate layer separation ? Currently the presentation layer only knows about the service layer..

    – Matt Burner
    Nov 22 '18 at 9:27













  • This probably means that you have placed your abstractions in the wrong place, because your presentation layer shouldn't have to depend on the business layer, if it only needs to use its abstractions. Your comment also seems to imply that your presentation layer directly calls UserAccount.Message, which would be a violation of layer separation, as the presentation layer should typically not call domain methods directly, but only do so through an interacting layer.

    – Steven
    Nov 22 '18 at 9:33











  • So far i have been sucessful with DI and using it in my controllers, but there is a scenario where i have to use the services in my custom mvc filters and for that i have to keep the filters parameter less and which is why i created this class called UserAccount to handle the services for my filter. We trying to create a base for the project.

    – Matt Burner
    Nov 22 '18 at 9:49











  • Ahhh, okay. So you're saying that UserAccount is not an entity but a component. In that case my answer is not helpful. Instead, your question seems a duplicate of this q/a.

    – Steven
    Nov 22 '18 at 10:02











  • So no DI for attributes looks like an invisible dead end? But there are several other articles that mention various methods of Filter injection, especially with ninject. Guess i'll go old school here nothing fancy :)

    – Matt Burner
    Nov 22 '18 at 10:28



















0














Using method 3, you need to register AccountService, i.e.



        builder.RegisterType<AccountService>().As<IAccountService>();
builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


And when you use UserAccount, make sure it is created using Autofac.






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53424958%2fproperty-method-injection-using-autofac-in-filter-attributes%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    You should prevent letting your container create data-centric objects, such as your UserAccount entity. This leads to complicated scenarios, such as the one you are in now.



    In general, your DI Container should resolve only components—those are the classes in your system that contain the application's behavior, without having any interesting state. Those types of classes are typically long lived, or at least. Data-centric objects, like entities, can best be created by hand. Not doing so would either lead to entities with big constructors, which easily causes the constructor over-injection code smell. As remedy, you might fall back on using Property Injection, but this causes a code smell of its own, caused Temporal Coupling.



    Instead, a better solution is to:




    1. Create entities by hand, opposed to using a DI Container

    2. Supply dependencies to the entity using Method Injection, opposed to using Property Injection


    With Method Injection, your UserAccount would as follows:



    // This answer assumes that this class is an domain entity.
    public class UserAccount
    {
    public Guid Id { get; set; }
    public byte PasswordHash { get; set; }

    public string Message(IAccountService accountService)
    {
    if (accountService == null) throw new ArgumentNullException(nameof(accountService));

    return accountService.Message();
    }
    }


    This does move the responsibility of supplying the dependency from the Composition Root to the entity's direct consumer, though. But as discussed above, this is intentional, as the Composition Root in general, and a DI Container in particular, should not be responsible of creating entities and other data-centric, short-lived objects.



    This does mean, however, that UserAccount's direct consumer should inject that dependency, and with that, know about existence of the dependency. But as that consumer would be a behavior-centric class, the typical solution is to use Constructor Injection at that stage:



    public class UserService : IUserService
    {
    private readonly IAccountService accountService;
    private readonly IUserAccountRepository repo;

    public UserService(IAccountService accountService, IUserAccountRepository repo)
    {
    this.accountService = accountService;
    this.repo = repo
    }

    public void DoSomething(Guid id)
    {
    UserAccount entity = this.repo.GetById(id);
    var message = entity.Message(this.accountService);
    }
    }





    share|improve this answer


























    • But this would mean that i have to make a reference of the business layer in my presentation layer in order to access that repository... is that OK? I mean wouldn't that violate layer separation ? Currently the presentation layer only knows about the service layer..

      – Matt Burner
      Nov 22 '18 at 9:27













    • This probably means that you have placed your abstractions in the wrong place, because your presentation layer shouldn't have to depend on the business layer, if it only needs to use its abstractions. Your comment also seems to imply that your presentation layer directly calls UserAccount.Message, which would be a violation of layer separation, as the presentation layer should typically not call domain methods directly, but only do so through an interacting layer.

      – Steven
      Nov 22 '18 at 9:33











    • So far i have been sucessful with DI and using it in my controllers, but there is a scenario where i have to use the services in my custom mvc filters and for that i have to keep the filters parameter less and which is why i created this class called UserAccount to handle the services for my filter. We trying to create a base for the project.

      – Matt Burner
      Nov 22 '18 at 9:49











    • Ahhh, okay. So you're saying that UserAccount is not an entity but a component. In that case my answer is not helpful. Instead, your question seems a duplicate of this q/a.

      – Steven
      Nov 22 '18 at 10:02











    • So no DI for attributes looks like an invisible dead end? But there are several other articles that mention various methods of Filter injection, especially with ninject. Guess i'll go old school here nothing fancy :)

      – Matt Burner
      Nov 22 '18 at 10:28
















    1














    You should prevent letting your container create data-centric objects, such as your UserAccount entity. This leads to complicated scenarios, such as the one you are in now.



    In general, your DI Container should resolve only components—those are the classes in your system that contain the application's behavior, without having any interesting state. Those types of classes are typically long lived, or at least. Data-centric objects, like entities, can best be created by hand. Not doing so would either lead to entities with big constructors, which easily causes the constructor over-injection code smell. As remedy, you might fall back on using Property Injection, but this causes a code smell of its own, caused Temporal Coupling.



    Instead, a better solution is to:




    1. Create entities by hand, opposed to using a DI Container

    2. Supply dependencies to the entity using Method Injection, opposed to using Property Injection


    With Method Injection, your UserAccount would as follows:



    // This answer assumes that this class is an domain entity.
    public class UserAccount
    {
    public Guid Id { get; set; }
    public byte PasswordHash { get; set; }

    public string Message(IAccountService accountService)
    {
    if (accountService == null) throw new ArgumentNullException(nameof(accountService));

    return accountService.Message();
    }
    }


    This does move the responsibility of supplying the dependency from the Composition Root to the entity's direct consumer, though. But as discussed above, this is intentional, as the Composition Root in general, and a DI Container in particular, should not be responsible of creating entities and other data-centric, short-lived objects.



    This does mean, however, that UserAccount's direct consumer should inject that dependency, and with that, know about existence of the dependency. But as that consumer would be a behavior-centric class, the typical solution is to use Constructor Injection at that stage:



    public class UserService : IUserService
    {
    private readonly IAccountService accountService;
    private readonly IUserAccountRepository repo;

    public UserService(IAccountService accountService, IUserAccountRepository repo)
    {
    this.accountService = accountService;
    this.repo = repo
    }

    public void DoSomething(Guid id)
    {
    UserAccount entity = this.repo.GetById(id);
    var message = entity.Message(this.accountService);
    }
    }





    share|improve this answer


























    • But this would mean that i have to make a reference of the business layer in my presentation layer in order to access that repository... is that OK? I mean wouldn't that violate layer separation ? Currently the presentation layer only knows about the service layer..

      – Matt Burner
      Nov 22 '18 at 9:27













    • This probably means that you have placed your abstractions in the wrong place, because your presentation layer shouldn't have to depend on the business layer, if it only needs to use its abstractions. Your comment also seems to imply that your presentation layer directly calls UserAccount.Message, which would be a violation of layer separation, as the presentation layer should typically not call domain methods directly, but only do so through an interacting layer.

      – Steven
      Nov 22 '18 at 9:33











    • So far i have been sucessful with DI and using it in my controllers, but there is a scenario where i have to use the services in my custom mvc filters and for that i have to keep the filters parameter less and which is why i created this class called UserAccount to handle the services for my filter. We trying to create a base for the project.

      – Matt Burner
      Nov 22 '18 at 9:49











    • Ahhh, okay. So you're saying that UserAccount is not an entity but a component. In that case my answer is not helpful. Instead, your question seems a duplicate of this q/a.

      – Steven
      Nov 22 '18 at 10:02











    • So no DI for attributes looks like an invisible dead end? But there are several other articles that mention various methods of Filter injection, especially with ninject. Guess i'll go old school here nothing fancy :)

      – Matt Burner
      Nov 22 '18 at 10:28














    1












    1








    1







    You should prevent letting your container create data-centric objects, such as your UserAccount entity. This leads to complicated scenarios, such as the one you are in now.



    In general, your DI Container should resolve only components—those are the classes in your system that contain the application's behavior, without having any interesting state. Those types of classes are typically long lived, or at least. Data-centric objects, like entities, can best be created by hand. Not doing so would either lead to entities with big constructors, which easily causes the constructor over-injection code smell. As remedy, you might fall back on using Property Injection, but this causes a code smell of its own, caused Temporal Coupling.



    Instead, a better solution is to:




    1. Create entities by hand, opposed to using a DI Container

    2. Supply dependencies to the entity using Method Injection, opposed to using Property Injection


    With Method Injection, your UserAccount would as follows:



    // This answer assumes that this class is an domain entity.
    public class UserAccount
    {
    public Guid Id { get; set; }
    public byte PasswordHash { get; set; }

    public string Message(IAccountService accountService)
    {
    if (accountService == null) throw new ArgumentNullException(nameof(accountService));

    return accountService.Message();
    }
    }


    This does move the responsibility of supplying the dependency from the Composition Root to the entity's direct consumer, though. But as discussed above, this is intentional, as the Composition Root in general, and a DI Container in particular, should not be responsible of creating entities and other data-centric, short-lived objects.



    This does mean, however, that UserAccount's direct consumer should inject that dependency, and with that, know about existence of the dependency. But as that consumer would be a behavior-centric class, the typical solution is to use Constructor Injection at that stage:



    public class UserService : IUserService
    {
    private readonly IAccountService accountService;
    private readonly IUserAccountRepository repo;

    public UserService(IAccountService accountService, IUserAccountRepository repo)
    {
    this.accountService = accountService;
    this.repo = repo
    }

    public void DoSomething(Guid id)
    {
    UserAccount entity = this.repo.GetById(id);
    var message = entity.Message(this.accountService);
    }
    }





    share|improve this answer















    You should prevent letting your container create data-centric objects, such as your UserAccount entity. This leads to complicated scenarios, such as the one you are in now.



    In general, your DI Container should resolve only components—those are the classes in your system that contain the application's behavior, without having any interesting state. Those types of classes are typically long lived, or at least. Data-centric objects, like entities, can best be created by hand. Not doing so would either lead to entities with big constructors, which easily causes the constructor over-injection code smell. As remedy, you might fall back on using Property Injection, but this causes a code smell of its own, caused Temporal Coupling.



    Instead, a better solution is to:




    1. Create entities by hand, opposed to using a DI Container

    2. Supply dependencies to the entity using Method Injection, opposed to using Property Injection


    With Method Injection, your UserAccount would as follows:



    // This answer assumes that this class is an domain entity.
    public class UserAccount
    {
    public Guid Id { get; set; }
    public byte PasswordHash { get; set; }

    public string Message(IAccountService accountService)
    {
    if (accountService == null) throw new ArgumentNullException(nameof(accountService));

    return accountService.Message();
    }
    }


    This does move the responsibility of supplying the dependency from the Composition Root to the entity's direct consumer, though. But as discussed above, this is intentional, as the Composition Root in general, and a DI Container in particular, should not be responsible of creating entities and other data-centric, short-lived objects.



    This does mean, however, that UserAccount's direct consumer should inject that dependency, and with that, know about existence of the dependency. But as that consumer would be a behavior-centric class, the typical solution is to use Constructor Injection at that stage:



    public class UserService : IUserService
    {
    private readonly IAccountService accountService;
    private readonly IUserAccountRepository repo;

    public UserService(IAccountService accountService, IUserAccountRepository repo)
    {
    this.accountService = accountService;
    this.repo = repo
    }

    public void DoSomething(Guid id)
    {
    UserAccount entity = this.repo.GetById(id);
    var message = entity.Message(this.accountService);
    }
    }






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 22 '18 at 10:04

























    answered Nov 22 '18 at 9:05









    StevenSteven

    127k17216334




    127k17216334













    • But this would mean that i have to make a reference of the business layer in my presentation layer in order to access that repository... is that OK? I mean wouldn't that violate layer separation ? Currently the presentation layer only knows about the service layer..

      – Matt Burner
      Nov 22 '18 at 9:27













    • This probably means that you have placed your abstractions in the wrong place, because your presentation layer shouldn't have to depend on the business layer, if it only needs to use its abstractions. Your comment also seems to imply that your presentation layer directly calls UserAccount.Message, which would be a violation of layer separation, as the presentation layer should typically not call domain methods directly, but only do so through an interacting layer.

      – Steven
      Nov 22 '18 at 9:33











    • So far i have been sucessful with DI and using it in my controllers, but there is a scenario where i have to use the services in my custom mvc filters and for that i have to keep the filters parameter less and which is why i created this class called UserAccount to handle the services for my filter. We trying to create a base for the project.

      – Matt Burner
      Nov 22 '18 at 9:49











    • Ahhh, okay. So you're saying that UserAccount is not an entity but a component. In that case my answer is not helpful. Instead, your question seems a duplicate of this q/a.

      – Steven
      Nov 22 '18 at 10:02











    • So no DI for attributes looks like an invisible dead end? But there are several other articles that mention various methods of Filter injection, especially with ninject. Guess i'll go old school here nothing fancy :)

      – Matt Burner
      Nov 22 '18 at 10:28



















    • But this would mean that i have to make a reference of the business layer in my presentation layer in order to access that repository... is that OK? I mean wouldn't that violate layer separation ? Currently the presentation layer only knows about the service layer..

      – Matt Burner
      Nov 22 '18 at 9:27













    • This probably means that you have placed your abstractions in the wrong place, because your presentation layer shouldn't have to depend on the business layer, if it only needs to use its abstractions. Your comment also seems to imply that your presentation layer directly calls UserAccount.Message, which would be a violation of layer separation, as the presentation layer should typically not call domain methods directly, but only do so through an interacting layer.

      – Steven
      Nov 22 '18 at 9:33











    • So far i have been sucessful with DI and using it in my controllers, but there is a scenario where i have to use the services in my custom mvc filters and for that i have to keep the filters parameter less and which is why i created this class called UserAccount to handle the services for my filter. We trying to create a base for the project.

      – Matt Burner
      Nov 22 '18 at 9:49











    • Ahhh, okay. So you're saying that UserAccount is not an entity but a component. In that case my answer is not helpful. Instead, your question seems a duplicate of this q/a.

      – Steven
      Nov 22 '18 at 10:02











    • So no DI for attributes looks like an invisible dead end? But there are several other articles that mention various methods of Filter injection, especially with ninject. Guess i'll go old school here nothing fancy :)

      – Matt Burner
      Nov 22 '18 at 10:28

















    But this would mean that i have to make a reference of the business layer in my presentation layer in order to access that repository... is that OK? I mean wouldn't that violate layer separation ? Currently the presentation layer only knows about the service layer..

    – Matt Burner
    Nov 22 '18 at 9:27







    But this would mean that i have to make a reference of the business layer in my presentation layer in order to access that repository... is that OK? I mean wouldn't that violate layer separation ? Currently the presentation layer only knows about the service layer..

    – Matt Burner
    Nov 22 '18 at 9:27















    This probably means that you have placed your abstractions in the wrong place, because your presentation layer shouldn't have to depend on the business layer, if it only needs to use its abstractions. Your comment also seems to imply that your presentation layer directly calls UserAccount.Message, which would be a violation of layer separation, as the presentation layer should typically not call domain methods directly, but only do so through an interacting layer.

    – Steven
    Nov 22 '18 at 9:33





    This probably means that you have placed your abstractions in the wrong place, because your presentation layer shouldn't have to depend on the business layer, if it only needs to use its abstractions. Your comment also seems to imply that your presentation layer directly calls UserAccount.Message, which would be a violation of layer separation, as the presentation layer should typically not call domain methods directly, but only do so through an interacting layer.

    – Steven
    Nov 22 '18 at 9:33













    So far i have been sucessful with DI and using it in my controllers, but there is a scenario where i have to use the services in my custom mvc filters and for that i have to keep the filters parameter less and which is why i created this class called UserAccount to handle the services for my filter. We trying to create a base for the project.

    – Matt Burner
    Nov 22 '18 at 9:49





    So far i have been sucessful with DI and using it in my controllers, but there is a scenario where i have to use the services in my custom mvc filters and for that i have to keep the filters parameter less and which is why i created this class called UserAccount to handle the services for my filter. We trying to create a base for the project.

    – Matt Burner
    Nov 22 '18 at 9:49













    Ahhh, okay. So you're saying that UserAccount is not an entity but a component. In that case my answer is not helpful. Instead, your question seems a duplicate of this q/a.

    – Steven
    Nov 22 '18 at 10:02





    Ahhh, okay. So you're saying that UserAccount is not an entity but a component. In that case my answer is not helpful. Instead, your question seems a duplicate of this q/a.

    – Steven
    Nov 22 '18 at 10:02













    So no DI for attributes looks like an invisible dead end? But there are several other articles that mention various methods of Filter injection, especially with ninject. Guess i'll go old school here nothing fancy :)

    – Matt Burner
    Nov 22 '18 at 10:28





    So no DI for attributes looks like an invisible dead end? But there are several other articles that mention various methods of Filter injection, especially with ninject. Guess i'll go old school here nothing fancy :)

    – Matt Burner
    Nov 22 '18 at 10:28













    0














    Using method 3, you need to register AccountService, i.e.



            builder.RegisterType<AccountService>().As<IAccountService>();
    builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


    And when you use UserAccount, make sure it is created using Autofac.






    share|improve this answer




























      0














      Using method 3, you need to register AccountService, i.e.



              builder.RegisterType<AccountService>().As<IAccountService>();
      builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


      And when you use UserAccount, make sure it is created using Autofac.






      share|improve this answer


























        0












        0








        0







        Using method 3, you need to register AccountService, i.e.



                builder.RegisterType<AccountService>().As<IAccountService>();
        builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


        And when you use UserAccount, make sure it is created using Autofac.






        share|improve this answer













        Using method 3, you need to register AccountService, i.e.



                builder.RegisterType<AccountService>().As<IAccountService>();
        builder.Register(c => new UserAccount { AccountService = c.Resolve<IAccountService>()});


        And when you use UserAccount, make sure it is created using Autofac.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 22 '18 at 9:22









        Phillip NganPhillip Ngan

        7,99244861




        7,99244861






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53424958%2fproperty-method-injection-using-autofac-in-filter-attributes%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            RAC Tourist Trophy