0

Assume you have a 3-layer application:

  1. UI layer (UI)
  2. Business layer (BLL)
  3. Data layer (DAL): references 32-bit DLL, so it must compile as x86

In a traditional app, the UI would reference the BLL and the BLL would reference the DAL. If the UI or BLL were set to the "Any CPU" platform, you would get a platform mismatch warning in the C# compiler. Thus, the x86 requirement (or "suggestion", since it's a warning) would bubble up to the UI and then the compiler would be happy.

In an app that uses IoC, assume you now add a 4th assembly, "Shared interfaces", which is referenced by all layers. Also, the UI references both the BLL and DAL and the BLL does not reference the DAL. In this case, the UI would see the platform mismatch warning. However, the BLL could stay as "Any CPU" and not receive any warnings. You can imagine the rest and how this could cause runtime errors.

Is my reasoning correct? Does IoC, or more broadly, loose coupling, by its nature tend to move some errors from compile-time to runtime?

Edit: So on rethinking this I realized my logic was flawed. The main assembly (UI) is the one that determines what platform the app runs under. So even if the BLL stayed as "Any CPU", the UI would force x86 and not cause any runtime errors. Even better, if the BLL is shared and another DAL implementation didn't require x86, the other app could stay as Any CPU since you're not dragging that reference along. Any other examples where some compiler errors move to runtime errors?

Nelson Rothermel
  • 9,436
  • 8
  • 62
  • 81

1 Answers1

1

Your reasoning has nothing to do with IoC or loose coupling. Those errors come in as soon as you start to mix 32bit/64bit now matter how you use the DLLs. The errors are on assembly level and not at class level like loose coupling or dependency injection.

jgauffin
  • 99,844
  • 45
  • 235
  • 372