Selfelected

A talk about pros and cons with O/RM

These are my pages from my talk about pros and cons with “fat” O/RM today.
As zip.

# O/RM

myname@omegapoint.se Göteborgs-kontoret

https://selfelected.com/
https://ideas.selfelected.com/
https://github.com/LosManos

# O/RM

myname@omegapoint.se Göteborgs-kontoret


Resultat: Ifrågasätt

# O/RM

myname@omegapoint.se Göteborgs-kontoret

Föredraget förutsätter en vag förståelse av ORM.
Fet orm (EF/Hibernate/cache). Micro-orm. (mappning av data och datatyper)
Att det är en översättning från RDb:ns mängdbaserade struktur till det imperativa språkets list-baserade; och tvärtom.

# O/RM

myname@omegapoint.se Göteborgs-kontoret

3 skäl
* Typsäkerhet
* Höger-vänster
* Refaktorering

# O/RM

myname@omegapoint.se Göteborgs-kontoret

Ökad komplexitet

Utsuddade gränser

Choke point

# O/RM

myname@omegapoint.se Göteborgs-kontoret

3 skäl
Typsäkerhet
ändras inte så ofta det så när det väl är mappat
Höger-vänster
ändras ofta i början men tenderar att stabiliseras
Refaktorering
man kan bara automatrefaktorera namn och typer. strukturer är manuellt arbete

# O/RM

myname@omegapoint.se Göteborgs-kontoret

https://www.selfelected.com/the-tree-reasons-to-use-an-o-rm/
https://dapper-tutorial.net/dapper

The three reasons to use an O/RM

1. Type security
2. Data copying Entity/Recordset
3. Faster turn around with a moving schema

If these 3 issues aren’t a problem in you case, be reluctant to use an O/RM as an O/RM brings a bunch of other problems.

Type security

When you get the Customer.Verified out of a database the code already knows it is a boolean. No explicit type casting or declaring is needed as it is done elswhere, once and for all.

Now this isn’t totally true but depends on whether LINQ or HQL (or for another O/RM) you are using. But basically it is true, because of solid Right-left copying

Right-left data copying

Copying data from a recordset to the Entity is done by the OR/M and configured once and for all. Unlike a programmer it won’t forget to copy a field in an obscure corner in your code base.

It isn’t hard to write a data copying function for this simple case and dragging a whole OR/M into the project is a lot of dependencies for little use.

Turn around

When the scheme is changing fast, like in the beginning of a project, or when prototyping, an O/RM is of great help to change in one place and let the coding tools and compiler do the rest of the changes in the project.

Schemes tend to solidify after a while and only change in small increments so speeding up the first 3 months for having a rucksack the coming 6 years might not be the best solution.

Where the business logic resides in an application with O/RM

In an O/RM solution the business logic often ends up in the very queries. Don’t mock them if you want to test business logic.

TL;DR

Some hundred years ago when Microsoft was pushing their first Entity framework and all examples were PresentationLayer<->DataAccessLayer someone asked “When one is using an O/RM; where is the business logic?”

After all this time I have finally found out. In the very queries.

This effects the unit tests.
Because what you often want to test with unit tests is business logic and mock out everything else. The call to the O/RM is often quite simple. Then comes some hefty Linq statement that translates to EF or nHibernate. Then follows some simple handling of the result. The main logic is in the O/RM call.
So when one mocks out the O/RM one mocks out a big part of the logic.

One solution is to not mock out the O/RM but instead mock the data retrieval beneath. I have not figured out how to do this.

Another solution is to do an integration test all the way to the database. My first try at this was messy but worked out. My second try was equally messy but also worked out and has returned the investment many times. My third, and present, try uses helper methods to set up the data and contrary to the earlier tries it doesn’t look messy any more.
This is inspired by my present gig where the QA guy wrote a simple DSL with fluent syntax to set up test data. I have not managed to replicate his library but am, presently, happy with helper methods.

Logging all SQL from nHibernate

There are several ways to see what queries are used by Nhibernate.

If you are doing serious development I recommend Nhprof. It costs some but it is second to none regarding overview and ease of use. One bug caught and it is paid for. The GUI is a bit clicky but does a good job of providing good S/N ratio.

Sniff the traffic. I have not done this seriously but once wrote an ADO sniffer since there wasn’t any profiler for MsAccess.

There there is tracing the RDB. Possibly gratis or even free, depending on database (I haven’t checked them all, only Microsoft’s one). In my experience it is too noisy to have running during the whole development cycle like one can do with Nhprof.

Then one can use Nhibernate itself to log. Check Nhibernate succinctly, chapter 12, for how to setup Nhibernate with Log4net. If you want to log through another framework the same author wrote an article.