2

Had a nice read about DI here in VBA:

https://rubberduckvba.wordpress.com/2016/07/05/oop-vba-pt-2-factories-and-cheap-hotels/

So now the next step would be use an IoC container in VBA. But I am wondering if that's even possible! I'm new to VBA and I cant figure out a few things:

  1. If done in VBA, VBA has no namespaces or Type equivalent from C#. So how would my lookup table store a unique key for a type?
  2. I thought about writing a com dll in C# and implement an IoC there but I cant figure out how to pass on a Interface type to the com interface. I cant even instantiate an interface to pass it as an object to com.

Am I reduced to just using strings and implement namespaces in VBA using modules?

PS: I did not find any exisiting implementation of IoC container for vba, so if there's any, I'm all ears!

schwarz
  • 501
  • 7
  • 28
  • 3
    First things first. Solve the problem of doing the equivalent of `CreateObject("MyVBAClass")` then you can start working on VBA IoC. That currently is a nontrivial problem. – this May 15 '19 at 15:26
  • 4
    Side note, I love seeing the [tag:dependency-injection] tag on the same post as the [tag:vba] tag on SO. – Mathieu Guindon May 15 '19 at 15:48

1 Answers1

4

That's the literal Holy Grail we've been chasing all along: the ability to instantiate a VBA class in-process, from C# code. The minute we figure out how to do this, an IoC container for VBA code becomes a definite possibility, and would absolutely ship with Rubberduck along with a full-blown mocking framework.

A VBA solution is probably not possible, since as @this alluded to, Newing up a class instance dynamically without a type system and without reflection, ...is pure black magic wizardry.

Setting aside the technical issues, one has to wonder: would an IoC container make such a huge difference?

The truth is, it wouldn't. Dependency Injection doesn't need an IoC container, "Poor Man's DI" works perfectly fine and, I may add, is even preferable.

I submit that if you've reached the point where an IoC container makes sense for your VBA project and you understand everything about DI and SOLID and write your code accordingly... then [not to take anything away from VBA but] my assessment is that you're completely beyond ready to move on from VBA and work with more OOP-capable languages, such as VB.NET or C# - and use everything you've learned about OOP in VBA while discovering a whole new range of possibilities through parameterized constructors, class inheritance, delegates, lambdas, LINQ, and so many other things.

Mathieu Guindon
  • 69,817
  • 8
  • 107
  • 235
  • 1
    I probably would add that this might be also a scenario where having a C# COM DLL to support additional work would be a good way to move forward. We don't have to scrap all the investments but use C# DLL to support the functionalities that are easier done in a .NET environment while providing all the capabilities you need in your current application. There are ways to xcopy deployment your C# COM DLL without any registrations. – this May 15 '19 at 15:55
  • @this, since I started with VBA, that is what I have been noticing too...you do the bare minimum in VBA and pass on as much as possible to C# :P – schwarz May 16 '19 at 07:08
  • Right then! @Mathieu Guindon, I will go for the poor man's DI like you suggested. IoC container does make sense for us but the point is, for us VBA is at the customer side. We do things in C++ or C#. But it was a cool idea to provide customers with interfaces + IoC to switch things with a change in some config file or something along those lines! – schwarz May 16 '19 at 07:13