Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 730011
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 14, 20262026-05-14T06:51:47+00:00 2026-05-14T06:51:47+00:00

It was recommended to me that, when using an IOC container, I should change

  • 0

It was recommended to me that, when using an IOC container, I should change this:

class Foobar: IFoobar, IDisposable {};

Into this:

interface IFoobar: IDisposable{};
class Foobar : IFoobar{};

I’m wondering if this is ok, or if it solves one problem and creates another. It certainly solves the problem where I badly want to do this:

using( IFoobar = myContainer.Resolve<IFoobar>() )
{ ... }

And now I know that any substitute won’t cause a run-time error.

On the other hand, now all my mock objects must handle IDisposable too. Am I right that most any mocking framework handles this easily? If yes, then perhaps this is a non-issue.

Or is it? Is there another hidden gotcha I should watch for? It certainly occurs to me that if I were using an IOC container not for unit tests / mocking, but for true service independence, then this might be a problem because perhaps only one of my swappable services actually deals with unmanaged resources (and now I’m having to implement empty “IDispose” operations in these other services).

Even this latter issue I suppose I could live with, for the sake of gaining the ability to employ the “using” statement as I demoed above. But am I following a popular convention, or am I missing an entirely different and better solution?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-14T06:51:47+00:00Added an answer on May 14, 2026 at 6:51 am

    Deriving an interface from IDisposable is in my opinion a design smell that indicates a Leaky Abstraction. As Nicholas Blumhardt put it:

    an interface […] generally shouldn’t be disposable. There’s no way for the one defining an interface to foresee all possible implementations of it – you can always come up with a disposable implementation of practically any interface.

    Consider why you want to add IDisposable to your interface. It’s probably because you have a particular implementation in mind. Hence, the implementation leaks into the abstraction.

    An DI Container worth its salt should know when it creates an instance of a disposable type. When you subsequently ask the container to release an object graph, it should automatically dispose the disposable components (if their time is up according to their lifestyles).

    I know that at least Castle Windsor and Autofac does this.

    So in your case, you should keep your type like this:

    class Foobar: IFoobar, IDisposable {};
    

    You may find Nicholas Blumhardt’s post The Relationship Zoo interesting as well – particularly the discussion about Owned<T>.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I'm using Prism and the Unity IoC container that comes along with Prism. However,
In a comment on this question , I saw a statement that recommended using
Using class table inheritance it is recommended that the subclass refers to the superclass
It is recommended that type names and virable names should avoid using abbreviations. It
It is widely recommended that JS files should be put at the bottom of
That’s a pretty major difference. This is why it’s always strongly recommended that you
I read somewhere that using .htaccess for 301 redirect is not recommended and that
Using a DI container (in this case, Ninject ) is it possible - -
I have heard that using exception trapping is not a recommended practice for number
I've heard that using 'em' for font size is recommended. I've tried it, but

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.