0

I am trying to design a way to use dependency injection with ORM tools so that it will be easy to replace them if needeed. The problem is that it seems impossimble to separate orm code from the program. Even if I am able to separate functionality like save, fetch etc. I cannot replace entity instances floating around.

I wondering if what I am trying yo achieve is reasonable. If so what are some good approaches to achieve this ?

Cemre Mengü
  • 18,062
  • 27
  • 111
  • 169
  • What do you mean by "impossible to seperate orm code from program?" You need to shed some more light about your program architecture so we can see why you say its "impossible" to achieve. – Yuval Itzchakov May 02 '14 at 06:45
  • 1
    Take a look at concept of [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design). In DDD your entities are the core layer of your application and they are oblivious to the used ORM technology. Persistence of your entities is hidden behind Repository abstractions and the repository implementations might use an ORM and translate your entities to ORM specific classes so they can be persisted. If you practice DDD, you will certainly not let your ORM dictate the shape of your entities: you are in control. – Steven May 02 '14 at 06:55

1 Answers1

0

You'll have a dependency on some level/layer of your app no matter what you do. I mean, as soon as you introduce 3rd party code, it needs to be connected to your app somewhere.

You could go with a repository pattern and create a repository project in your solution and keep all the LLBLGen-related code in there. You would do all your DB interaction through it and you would have to pass some DTO-style objects to and from it to avoid leakage. You would also have to do all the mapping between LLBLGen and your DTO's in the repository.

So, if we're talking about a webapp, you could have something like WebAPI <-> Business Layer <-> Repository Layer <-> ORM

Also, in reality it's highly unlikely that you're going decide to swap out the ORM for a different one (and especially LLBLGen because it's a really good ORM) so you're perhaps slightly overthinking this bit. You should pick an ORM wisely up front and stick with it. If you already know you want to swap it out later, why not do it right away? And you typically wouldn't be using DI with something like LLBLGen entity objects anyway (not saying you couldn't). It's kind of like saying that you would like to use DI for DateTime in case you decide to instead use Noda Time to handle dates. The main point of DI is to make your code testable, and even with say having LLBLGen entities in your Business layer, that's wouldn't be an issue, you would still be able to mock repo methods and test the business layer nicely.

Some clarifications:
DTO = Data Transfer Objects
DI = Dependency Injection

Amir Hossein Baghernezad
  • 3,616
  • 27
  • 28
tkit
  • 8,082
  • 6
  • 40
  • 71
  • DateTime is a data. Data should be put in a DTO. So in this case we can change Datetime to NodaTime Just by changing the DTO signature If we ever wanted. So we can achieve DI with things like DateTime. – Amir Hossein Baghernezad Nov 08 '17 at 14:11
  • @TechJS yes, you could do that, but that's not really DI, it's just object construction. and it slightly missed the point that I tried to make – tkit Nov 08 '17 at 14:27
  • What if we want to use ORM with not an only data object. Assume we have an object `A` that has a property `databaseHandler` which is a dependency relating to a database class. and the `databaseHandler` class has a `config` property which is a dictionary (pythonic speaking, probabely HashMap in java, Not sure what in C#). If we save object `A` to database, does it save the relating `config` property (a dictionary) that is for one of its dependencies? How does ORM really work? Should we specify the properties we want to make persistent? – Amir Hossein Baghernezad Nov 08 '17 at 14:55
  • @TechJS if you're interested in the internals of how LLBLGen ORM (that OP asked about) works, you should consult their docs. In LLBLGen you can't just save any object to the DB. It needs to be an LLBLGen Entity type object and it won't let you set something totally random to it because these Entity classes are generated by LLBLGen and are strongly typed. They do support recursive saving. I don't see how all these subquestions are relevant to OP's question and I feel we're getting a bit out of scope of the original question. – tkit Nov 08 '17 at 15:05