Inject parent into child class with Ninject
0
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
asked Nov 12 at 8:14
Jürgen Steinblock
18.7k1682148
add a comment |
0
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
asked Nov 12 at 8:14
Jürgen Steinblock
18.7k1682148
Why doesChildneed 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 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].ControlorxDocument.Element("SomeElement").Parentas a reference. Also, the desired approach to configure Ninject to use a plainIChildimplementation 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 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 at 8:13
add a comment |
0
0
0
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
asked Nov 12 at 8:14
Jürgen Steinblock
18.7k1682148
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 at 8:14
Jürgen Steinblock
18.7k1682148
asked Nov 12 at 8:14
Jürgen Steinblock
18.7k1682148
asked Nov 12 at 8:14
Jürgen Steinblock
18.7k1682148
asked Nov 12 at 8:14
Jürgen Steinblock
18.7k1682148
asked Nov 12 at 8:14
Jürgen Steinblock
18.7k1682148
18.7k1682148
Why doesChildneed 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 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].ControlorxDocument.Element("SomeElement").Parentas a reference. Also, the desired approach to configure Ninject to use a plainIChildimplementation 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 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 at 8:13
add a comment |
Why doesChildneed 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 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].ControlorxDocument.Element("SomeElement").Parentas a reference. Also, the desired approach to configure Ninject to use a plainIChildimplementation 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 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 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 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 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 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 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 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 at 8:13
add a comment |
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
);
);
draft saved
draft discarded
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
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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
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
Childneed 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 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].ControlorxDocument.Element("SomeElement").Parentas a reference. Also, the desired approach to configure Ninject to use a plainIChildimplementation 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 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 at 8:13