Question

I need to pick up many video files from a directory and split them into audio and video (by ffmpeg) and convert into mxf and encrypt by third party (open source) command line tools. On encryption the tool generates keys and writes them into files with random names. So I need a background-worker (BGW) and a file-watcher (FW) (both of them has a dispose method so I believe they are linked to unmanaged resources and should be disposed after use). I have created a class - DrmConvertible (DC) which has reference to original video path and on a function call it does what I need as mentioned above (model). There is another class which reads all files from the directory and creates a list of DC object (like viewModel but not exactly).


Where should I declare the FW and BGW ?

  1. Inside the DC class (maintains encapsulation but every object has an instance of it - may be 1000s).
  2. If point-01 then should it be global and initialized in constructor - it goes out of scope with the class (I don't know when).
  3. If point-01 then should it be local within the function and I explicitly initialize and dispose it within the function (do I also register and unregister events).
  4. In the class (global) and static variable so that only one instance is maintained and it goes out of scope with class (I don't know when). It is the same as abstracting it in a helper class or service and initializing once.
  5. In the outer class (viewmodel which has the list of DC objects - it breaks encapsulation but easier - in the current context) ?

Is there a guideline for such a situation (what should go in data holder and what should go in the data-list holder) ? Please don't ask me to read the book code-complete [ ;) ]

Was it helpful?

Solution

I prefer to dispose objects as soon as they are not needed anymore. There are taking up resources, obviously, so in my opinion your best bet would be to initialize and dispose them as close together as possible.

So I vote for your item 3.

As your objects implement the IDisposable interface, you can easily use the using statement, which even calls the Dispose() method automatically. It does not get any easier or comfortable than that.

And yes, you will need to unregister the event subscriptions! If you don't, the GarbageCollector will keep your objects alive, even though they may have already gone out of scope. This would then result in a serious memory leak, as you cannot dispose an out-of-scope object.

If you do not immediately dispose your objects, you are responsible for making sure that their resources will be freed up later. That always means more maintenance overhead. All objects that reference unmanaged resources that are not cleaned up right away after use have to implement their own Dispose() method. This might result in a longer disposing hierarchy.

Therefore, if you were implementing it like in items 1, 2, 4, and 5 you would still need to make sure that some other class calls Dispose() on the DC. And that might prove difficult, as you already said by yourself that you cannot determine when the DC goes out scope. So do not do that! You're getting into troubles here.

So, again, I vote for item 3. At that point you have full control over the lifetime(s) of your objects and when exactly they are not needed anymore.

OTHER TIPS

Sounds, to me, like 5 is your best bet.

I would be looking to have a 'composition root' that creates the BGW and FW once and then injects them into whatever needs them. The 'composition root' can then dispose when all is done.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top