Question

In all the examples I have seen, ORM’s tend to be used directly or behind some kind of DAL repository (presumably so that they can be swapped out in the future).

I am no fan of direct ORM use as it will be hard to swap out, but i am equally no fan of losing the full domain change tracking it provides!

In the past I would have written a data mapper class (Fowler) for each object in my domain, but I have learnt through experience that this CRUD coding drains around 1/3 of my time.

I a realize that changing my data access strategy is rather unlikely (I have never had to do so before) but I am really concerned that by using an ORM directly I will be locking myself into using it until the end of time.

I have been thinking about wrapping the ORM (no decision on the ORM itself yet) in a generic ORM container and passing this around to finder classes for each of the domain objects. However, I am totally unsure what a generic ORM wrapper class would look like!

Has anyone got any real life advise here? Please don’t feel it nessecary to sugar coat your answers!!

Answer 1

The repository has a number of functions:

1. It allows for unit testing with a mock implementation
2. It allows you to hide the full implementation of the ORM from the consumer, and implement security functions
3. It provides a layer of abstraction for business logic (although some people use a separate service layer for this), and
4. It allows you to change the ORM implementation, if necessary.

Another container to genericize your ORM feels like overengineering to me. As you pointed out, it is unlikely that you will ever change your underlying implementation, but if you do, your repositories seem like the sensible place to do it.