Property / method injection using Autofac in filter attributes
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
add a comment |
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
Is theUserAccount
object created by Autofac, too? If you create it manually (by using thenew
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 useUserAccount
.
– 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
add a comment |
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
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
c# dependency-injection autofac property-injection
edited Nov 22 '18 at 10:50
Steven
127k17216334
127k17216334
asked Nov 22 '18 at 6:22
Matt BurnerMatt Burner
867
867
Is theUserAccount
object created by Autofac, too? If you create it manually (by using thenew
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 useUserAccount
.
– 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
add a comment |
Is theUserAccount
object created by Autofac, too? If you create it manually (by using thenew
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 useUserAccount
.
– 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
add a comment |
2 Answers
2
active
oldest
votes
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:
- Create entities by hand, opposed to using a DI Container
- 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);
}
}
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 callsUserAccount.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 thatUserAccount
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
add a comment |
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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:
- Create entities by hand, opposed to using a DI Container
- 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);
}
}
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 callsUserAccount.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 thatUserAccount
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
add a comment |
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:
- Create entities by hand, opposed to using a DI Container
- 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);
}
}
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 callsUserAccount.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 thatUserAccount
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
add a comment |
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:
- Create entities by hand, opposed to using a DI Container
- 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);
}
}
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:
- Create entities by hand, opposed to using a DI Container
- 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);
}
}
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 callsUserAccount.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 thatUserAccount
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
add a comment |
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 callsUserAccount.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 thatUserAccount
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 22 '18 at 9:22
Phillip NganPhillip Ngan
7,99244861
7,99244861
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Is the
UserAccount
object created by Autofac, too? If you create it manually (by using thenew
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