1

I have a solution structured like so:

  • Models assembly
  • Data assembly - defines repository interfaces and a base repository class
  • ORM assembly - implements repository interfaces & inherits base repository class ^
  • Business assembly - has a reference to the data assembly, and dynamically pulls in the ORM object via MEF (no explicit reference to the ORM assembly)
  • UI assembly(s)

In this fashion, I can easily swap out the ORM, if we decide to go with something else.

I'm curious if it's possible to have similar functionality with Unity. I want to decouple my business logic from the underlying ORM. From what I've read, unity mainly works at compile time and MEF is at runtime. That being said, is it possible to decouple with unity in such a way that my business layer has no reference to the ORM, but instead just the interfaces that it implements from the data assembly? How can Unity define what implements the interface without having a reference to the implementing assembly?

Currently, with MEF, no assembly has a reference to the ORM (other than when the business layer dynamically pulls it in at runtime to discover parts and fill the interface with an object). I would prefer to continue working along these lines and would like to know if I can do that with Unity.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Chris Klepeis
  • 9,783
  • 16
  • 83
  • 149

1 Answers1

1

To do the same with Unity, you typically have the ORM interfaces and their implementation in separate assemblies.

For example, in the Project.Orm.Interface assembly you would define the interfaces that any ORM must implement; the rest of your solution would have references to Project.Orm.Interface. This way, no part of your application has references to any concrete ORM implementation.

The Project.Orm.ConcreteImplementation assembly would also reference Project.Orm.Interface and register the concrete types in the container using the interface types they implement (much like the dependent code resolves the types by asking for the interfaces they implement).

In the context of Prism, there would be a dynamically discovered IModule that loads Project.Orm.ConcreteImplementation and registers the types in the container at module initialization time.

Jon
  • 428,835
  • 81
  • 738
  • 806
  • thanks, makes sense. Sounds like I would just have to add a module dependency then to other modules that use that ORM? – Chris Klepeis Apr 04 '11 at 13:55
  • 1
    @ChrisKlepeis: Not quite, you don't want to introduce dependency to a specific ORM implementation. The modules that use the ORM would simply try to resolve an `IDataContext` or equivalent from the container. If they cannot, then raising a runtime error would be probably the way to go. Alternatively, the module-loading code could inquire each module "what type of module are you?"; if a module says "ORM" and doesn't register appropriate types, or if no module at all says "ORM", then your application knows it cannot continue. – Jon Apr 04 '11 at 13:59