The wages of sin: Inverse leaky abstractions

this time, this is a review of the sharp commerce application. again, i have stumbled upon the application by pure chance, and i have very little notion about who wrote it.

as you might have noticed, i am pretty big fan of the nhibernate futures feature (might be because i wrote it ), so i was encouraged when i saw it used in the project. it can drastically help the performance of the system.

except, that then i saw how it is being used.

which is then called from currencyservice:

which is then called…

do you see that? we take the nice future query that we have, and turn it into a standard query, blithely crashing any chance to actually optimize the data access of the system.

the problem is that from the service api, there is literally nothing to tell you that you need to order your calls so all the data access happens up front, and it is easy to make mistakes such as this. the problem is that there is meaning lost at any additional abstraction layer, and pretty soon whatever good intention you had when you wrote a particular layer, 7 layers removed, you can’t really remember what is the best way to approach something.