Dependencies and DefaultReuse - need advice

Nov 25, 2009 at 8:31 PM

Hi guys,

I have an application in which a lot of classes ultimately depend on repository objects. These repositories are constructed by passing in a server name which they use to build the URI for the web services they talk to. I've added the server name to the project's user properties, so my repositories are registered like this:

container.Register<IFooRepository>(
    c => new FooRepository(Properties.Settings.Default.Server);

It's a bit clunky, but it works.

The problem I have is that the user could decide to change the server at any time, and when they do so, any existing repositories are invalid. To get around this problem I've set the DefaultReuse on the container to "None" so that everything's constructed new every time it's requested.

Can someone suggest a way that I could reuse my repository classes (and therefore all the classes that have them as dependencies) as long as the Server setting doesn't change? Once the user changes the server, I need the next call to container.Resolve<IFooRepository>() to return a new instance using the new server name.

I was thinking of registering the default settings as an instance in a "parent" container, and giving my application a way to spawn off a child container with all the repositories registered in it. Whenever the server name changed, the app would ditch that child container and create another one. This doesn't seem practical, though, because it feels like my app would have to have too much "knowledge" about containers (so that it could re-create one when the options dialog closes).

Coordinator
Nov 29, 2009 at 11:12 AM
unless repository object creation is expensive or holds to unmanaged resources for its lifetime (which it shouldn't IMO), I don't see a problem in re-creating it every time.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471


On Sat, Nov 28, 2009 at 15:09, mabster <notifications@codeplex.com> wrote:

From: mabster

Hi guys,

I have an application in which a lot of classes ultimately depend on repository objects. These repositories are constructed by passing in a server name which they use to build the URI for the web services they talk to. I've added the server name to the project's user properties, so my repositories are registered like this:

container.Register<IFooRepository>(
    c => new FooRepository(Properties.Settings.Default.Server);

It's a bit clunky, but it works.

The problem I have is that the user could decide to change the server at any time, and when they do so, any existing repositories are invalid. To get around this problem I've set the DefaultReuse on the container to "None" so that everything's constructed new every time it's requested.

Can someone suggest a way that I could reuse my repository classes (and therefore all the classes that have them as dependencies) as long as the Server setting doesn't change? Once the user changes the server, I need the next call to container.Resolve<IFooRepository>() to return a new instance using the new server name.

I was thinking of registering the default settings as an instance in a "parent" container, and giving my application a way to spawn off a child container with all the repositories registered in it. Whenever the server name changed, the app would ditch that child container and create another one. This doesn't seem practical, though, because it feels like my app would have to have too much "knowledge" about containers (so that it could re-create one when the options dialog closes).

Read the full discussion online.

To add a post to this discussion, reply to this email (funq@discussions.codeplex.com)

To start a new discussion for this project, email funq@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Nov 29, 2009 at 8:20 PM
Yeah neither is true, but I guess the fact that DefaultReuse isn't "None" by default had me thinking that caching instances of everything was the preferred way to go. Certainly it's not expensive to create everything down the dependency tree each time it's needed.
Matt

From: [email removed]
Sent: Sunday, November 29, 2009 11:12 PM
To: [email removed]
Subject: Re: Dependencies and DefaultReuse - need advice [funq:76256]

From: dcazzulino

unless repository object creation is expensive or holds to unmanaged resources for its lifetime (which it shouldn't IMO), I don't see a problem in re-creating it every time.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471


On Sat, Nov 28, 2009 at 15:09, mabster <notifications@codeplex.com> wrote:

From: mabster

Hi guys,

I have an application in which a lot of classes ultimately depend on repository objects. These repositories are constructed by passing in a server name which they use to build the URI for the web services they talk to. I've added the server name to the project's user properties, so my repositories are registered like this:

container.Register<IFooRepository>(
    c => new FooRepository(Properties.Settings.Default.Server);

It's a bit clunky, but it works.

The problem I have is that the user could decide to change the server at any time, and when they do so, any existing repositories are invalid. To get around this problem I've set the DefaultReuse on the container to "None" so that everything's constructed new every time it's requested.

Can someone suggest a way that I could reuse my repository classes (and therefore all the classes that have them as dependencies) as long as the Server setting doesn't change? Once the user changes the server, I need the next call to container.Resolve<IFooRepository>() to return a new instance using the new server name.

I was thinking of registering the default settings as an instance in a "parent" container, and giving my application a way to spawn off a child container with all the repositories registered in it. Whenever the server name changed, the app would ditch that child container and create another one. This doesn't seem practical, though, because it feels like my app would have to have too much "knowledge" about containers (so that it could re-create one when the options dialog closes).

Read the full discussion online.

To add a post to this discussion, reply to this email (funq@discussions.codeplex.com)

To start a new discussion for this project, email funq@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com