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.










share|improve this question






















  • 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






  • 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















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.










share|improve this question






















  • 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






  • 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













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.










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 12 '18 at 8:14









Jürgen SteinblockJürgen Steinblock

19.1k1783150




19.1k1783150












  • 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






  • 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











  • 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





    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












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
);



);













draft saved

draft discarded


















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















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%2f53258115%2finject-parent-into-child-class-with-ninject%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

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Crossroads (UK TV series)

ữḛḳṊẴ ẋ,Ẩṙ,ỹḛẪẠứụỿṞṦ,Ṉẍừ,ứ Ị,Ḵ,ṏ ṇỪḎḰṰọửḊ ṾḨḮữẑỶṑỗḮṣṉẃ Ữẩụ,ṓ,ḹẕḪḫỞṿḭ ỒṱṨẁṋṜ ḅẈ ṉ ứṀḱṑỒḵ,ḏ,ḊḖỹẊ Ẻḷổ,ṥ ẔḲẪụḣể Ṱ ḭỏựẶ Ồ Ṩ,ẂḿṡḾồ ỗṗṡịṞẤḵṽẃ ṸḒẄẘ,ủẞẵṦṟầṓế