0

In my ASP.NET MVC app I have a controller like this:

[HttpPost]
public ActionResult CreateTestCategory(TestCategory testCategory)
{
    BLL.Admin.CreateTestCategory obj = new BLL.Admin.CreateTestCategory();
    obj.Create(testCategory.TestCategoryName);
    //((IDisposable)obj).Dispose();

    return RedirectToAction("TestCategory", "Admin");
}  

Here the BLL.Admin.CreateTestCategory is in another layer and it does not implement IDisposable. It just makes some EF database calls and those calls are disposed in their own way using Repository pattern, so no worries there. But in this controller I created an object obj of that class. After working it out I want to destroy/dispose that obj manually. So the line I commented out, is this the only way to dispose obj?

The reason I did not make BLL.Admin.CreateTestCategory to implement IDisposable is that, there might be a hundred classes like it. I dont want to go to each one and implement IDisposable then use the using block, its painful, instead I want to just dispose it manually after creating it. I also dont want to wait for GC. So what is the perfect reliable way of doing it?

Wahid Masud
  • 993
  • 10
  • 35
  • 6
    So suppose you decided to implement `IDisposable` for that class (you don't want to, but suppose you tried), what would you write in `Dispose()` implementation? – Evk Apr 08 '18 at 13:49
  • 2
    Given the comment of @Evk, maybe you could implement it on the [destructor](https://learn.microsoft.com/dotnet/csharp/programming-guide/classes-and-structs/destructors). – Felipe Oriani Apr 08 '18 at 13:50
  • 1
    If you don't have anything uamanaged in those classes then using IDisposable is overkill. And it is best to allow GC work on its own. Objects created in Controller are very common and they gets disposed by GC when the controller instance is destroyed. – Chetan Apr 08 '18 at 13:50
  • @Evk exactly, i dont have any resources to dispose for that class. it just accepts some data from this controller, modify it, then calls the UnitOfWork class. so i was just wondering what should i do with this class inside this controller. should i leave it as it is or is there any better way. – Wahid Masud Apr 08 '18 at 13:54
  • 2
    If you don't have anything to dispose then let the *GC* to do its work. Just make sure that all `repository`s and `unit of work`s are disposing managed resources. – Fabjan Apr 08 '18 at 13:55
  • 2
    You cannot just reclaim memory from instantiated .NET object, only GC can do this. Implementing `IDisposable` and calling `Dispose` also doesn't do that. So you should just leave it as is and let GC do its job. – Evk Apr 08 '18 at 13:56
  • @FelipeOriani maybe destructor is still a lot of work given that i have lot of classes like this in many controllers. – Wahid Masud Apr 08 '18 at 14:00
  • 1
    alright guys GC wins then. appreciate your help. – Wahid Masud Apr 08 '18 at 14:01
  • Read the comment by @evk carefully because that comment is the answer to your question. In other words, if you create the `Dispose` method and you do nothing in it, then it means there is nothing to dispose. Therefore, there is really no point in implementing `IDisposable` – CodingYoshi Apr 08 '18 at 14:01
  • yes yes of course. thats also one of my reasons not to implement IDisposable. – Wahid Masud Apr 08 '18 at 14:03
  • 2
    On a side note, it is not good practice to name classes as *action verbs*. This is because they sound like a method i.e. `CreateTestCategory` sounds like a method. It is better practice to name them as a *noun* so they sound like an object. Thus a better name would be `TestCategoryCreator` or `TestCategoryService` or `TestCategoryManager`. – CodingYoshi Apr 08 '18 at 14:08
  • @CodingYoshi well thats something useful. i would take `TestCategoryService` cause it sounds great. thanks man. – Wahid Masud Apr 08 '18 at 14:12

1 Answers1

2

This question has already been answered in a roundabout way in the comments on the question itself, but to sum up what CodingYoshi, Evk, and Fabjan have said there...

IDisposable is for cleaning up resources that are not managed by the .NET runtime. If you need to clean up connections to databases, file locks, etc, then you really should be using IDisposable. For managed memory, the garbage collector will take care of it better than you can in almost any circumstances. Destructors can be used, but are generally not necessary.

References:

JamesFaix
  • 8,050
  • 9
  • 37
  • 73