Inject parent into child class with Ninject
Let's say I have the following code where a dependency needs a reference to the parent.
public class Parent: IParent
private readonly IChild child;
public Parent()
this.child = new Child(this);
public class Child
private readonly IParent parent;
public Child(IParent parent)
this.parent = parent;
Now I want to use ICO with Ninject to refactor this code to inject a IChild instance, which itself takes a reference to parent
public class Parent: IParent
private readonly IChild child;
public Parent(IChild child)
this.child = child;
Is it possible to tell nancy to always use the current instance to resolve the dependency.
Obviously I could use a factory pattern, in fact that's what I do atm with Ninject.Extensions.Factory.
public class Parent: IParent
private readonly IChild child;
public Parent(Func<IParent, IChild> childFactory)
this.child = childFactory(this);
But I am wondering if I could refactor this to avoid the factory.
dependency-injection inversion-of-control ninject
add a comment |
Let's say I have the following code where a dependency needs a reference to the parent.
public class Parent: IParent
private readonly IChild child;
public Parent()
this.child = new Child(this);
public class Child
private readonly IParent parent;
public Child(IParent parent)
this.parent = parent;
Now I want to use ICO with Ninject to refactor this code to inject a IChild instance, which itself takes a reference to parent
public class Parent: IParent
private readonly IChild child;
public Parent(IChild child)
this.child = child;
Is it possible to tell nancy to always use the current instance to resolve the dependency.
Obviously I could use a factory pattern, in fact that's what I do atm with Ninject.Extensions.Factory.
public class Parent: IParent
private readonly IChild child;
public Parent(Func<IParent, IChild> childFactory)
this.child = childFactory(this);
But I am wondering if I could refactor this to avoid the factory.
dependency-injection inversion-of-control ninject
Why doesChild
need a reference to its parent? Such circular dependencies can, IME, always be avoided, and the resulting code will be easier to use and maintain.
– Mark Seemann
Nov 19 '18 at 20:16
I do not agree. There are good reasons and use cases to have a child reference it parents and a parent referencing its child(s). Take the Windows Formscontrol.Controls[0].Control
orxDocument.Element("SomeElement").Parent
as a reference. Also, the desired approach to configure Ninject to use a plainIChild
implementation instead of a factory, would eliminate the requirement to have a constructor which takes a parent as an argument, which is in fact implementation specific. So I see nothing wrong with my approach.
– Jürgen Steinblock
Nov 20 '18 at 7:47
1
I don't think that "Windows Forms does it that way" is an argument that something is well-designed :) The mere fact that you're having trouble with the design related to NInject is a tautological indication that the design is causing you trouble.
– Mark Seemann
Nov 20 '18 at 8:13
add a comment |
Let's say I have the following code where a dependency needs a reference to the parent.
public class Parent: IParent
private readonly IChild child;
public Parent()
this.child = new Child(this);
public class Child
private readonly IParent parent;
public Child(IParent parent)
this.parent = parent;
Now I want to use ICO with Ninject to refactor this code to inject a IChild instance, which itself takes a reference to parent
public class Parent: IParent
private readonly IChild child;
public Parent(IChild child)
this.child = child;
Is it possible to tell nancy to always use the current instance to resolve the dependency.
Obviously I could use a factory pattern, in fact that's what I do atm with Ninject.Extensions.Factory.
public class Parent: IParent
private readonly IChild child;
public Parent(Func<IParent, IChild> childFactory)
this.child = childFactory(this);
But I am wondering if I could refactor this to avoid the factory.
dependency-injection inversion-of-control ninject
Let's say I have the following code where a dependency needs a reference to the parent.
public class Parent: IParent
private readonly IChild child;
public Parent()
this.child = new Child(this);
public class Child
private readonly IParent parent;
public Child(IParent parent)
this.parent = parent;
Now I want to use ICO with Ninject to refactor this code to inject a IChild instance, which itself takes a reference to parent
public class Parent: IParent
private readonly IChild child;
public Parent(IChild child)
this.child = child;
Is it possible to tell nancy to always use the current instance to resolve the dependency.
Obviously I could use a factory pattern, in fact that's what I do atm with Ninject.Extensions.Factory.
public class Parent: IParent
private readonly IChild child;
public Parent(Func<IParent, IChild> childFactory)
this.child = childFactory(this);
But I am wondering if I could refactor this to avoid the factory.
dependency-injection inversion-of-control ninject
dependency-injection inversion-of-control ninject
asked Nov 12 '18 at 8:14
Jürgen SteinblockJürgen Steinblock
19.1k1783150
19.1k1783150
Why doesChild
need a reference to its parent? Such circular dependencies can, IME, always be avoided, and the resulting code will be easier to use and maintain.
– Mark Seemann
Nov 19 '18 at 20:16
I do not agree. There are good reasons and use cases to have a child reference it parents and a parent referencing its child(s). Take the Windows Formscontrol.Controls[0].Control
orxDocument.Element("SomeElement").Parent
as a reference. Also, the desired approach to configure Ninject to use a plainIChild
implementation instead of a factory, would eliminate the requirement to have a constructor which takes a parent as an argument, which is in fact implementation specific. So I see nothing wrong with my approach.
– Jürgen Steinblock
Nov 20 '18 at 7:47
1
I don't think that "Windows Forms does it that way" is an argument that something is well-designed :) The mere fact that you're having trouble with the design related to NInject is a tautological indication that the design is causing you trouble.
– Mark Seemann
Nov 20 '18 at 8:13
add a comment |
Why doesChild
need a reference to its parent? Such circular dependencies can, IME, always be avoided, and the resulting code will be easier to use and maintain.
– Mark Seemann
Nov 19 '18 at 20:16
I do not agree. There are good reasons and use cases to have a child reference it parents and a parent referencing its child(s). Take the Windows Formscontrol.Controls[0].Control
orxDocument.Element("SomeElement").Parent
as a reference. Also, the desired approach to configure Ninject to use a plainIChild
implementation instead of a factory, would eliminate the requirement to have a constructor which takes a parent as an argument, which is in fact implementation specific. So I see nothing wrong with my approach.
– Jürgen Steinblock
Nov 20 '18 at 7:47
1
I don't think that "Windows Forms does it that way" is an argument that something is well-designed :) The mere fact that you're having trouble with the design related to NInject is a tautological indication that the design is causing you trouble.
– Mark Seemann
Nov 20 '18 at 8:13
Why does
Child
need a reference to its parent? Such circular dependencies can, IME, always be avoided, and the resulting code will be easier to use and maintain.– Mark Seemann
Nov 19 '18 at 20:16
Why does
Child
need a reference to its parent? Such circular dependencies can, IME, always be avoided, and the resulting code will be easier to use and maintain.– Mark Seemann
Nov 19 '18 at 20:16
I do not agree. There are good reasons and use cases to have a child reference it parents and a parent referencing its child(s). Take the Windows Forms
control.Controls[0].Control
or xDocument.Element("SomeElement").Parent
as a reference. Also, the desired approach to configure Ninject to use a plain IChild
implementation instead of a factory, would eliminate the requirement to have a constructor which takes a parent as an argument, which is in fact implementation specific. So I see nothing wrong with my approach.– Jürgen Steinblock
Nov 20 '18 at 7:47
I do not agree. There are good reasons and use cases to have a child reference it parents and a parent referencing its child(s). Take the Windows Forms
control.Controls[0].Control
or xDocument.Element("SomeElement").Parent
as a reference. Also, the desired approach to configure Ninject to use a plain IChild
implementation instead of a factory, would eliminate the requirement to have a constructor which takes a parent as an argument, which is in fact implementation specific. So I see nothing wrong with my approach.– Jürgen Steinblock
Nov 20 '18 at 7:47
1
1
I don't think that "Windows Forms does it that way" is an argument that something is well-designed :) The mere fact that you're having trouble with the design related to NInject is a tautological indication that the design is causing you trouble.
– Mark Seemann
Nov 20 '18 at 8:13
I don't think that "Windows Forms does it that way" is an argument that something is well-designed :) The mere fact that you're having trouble with the design related to NInject is a tautological indication that the design is causing you trouble.
– Mark Seemann
Nov 20 '18 at 8:13
add a comment |
0
active
oldest
votes
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%2f53258115%2finject-parent-into-child-class-with-ninject%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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%2f53258115%2finject-parent-into-child-class-with-ninject%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
Why does
Child
need a reference to its parent? Such circular dependencies can, IME, always be avoided, and the resulting code will be easier to use and maintain.– Mark Seemann
Nov 19 '18 at 20:16
I do not agree. There are good reasons and use cases to have a child reference it parents and a parent referencing its child(s). Take the Windows Forms
control.Controls[0].Control
orxDocument.Element("SomeElement").Parent
as a reference. Also, the desired approach to configure Ninject to use a plainIChild
implementation instead of a factory, would eliminate the requirement to have a constructor which takes a parent as an argument, which is in fact implementation specific. So I see nothing wrong with my approach.– Jürgen Steinblock
Nov 20 '18 at 7:47
1
I don't think that "Windows Forms does it that way" is an argument that something is well-designed :) The mere fact that you're having trouble with the design related to NInject is a tautological indication that the design is causing you trouble.
– Mark Seemann
Nov 20 '18 at 8:13