This reminds me a lot of Gary Bernhardt's <i>Boundaries</i> talk and the associated idea of "functional core, imperative shell". For anyone who found this article interesting, you might also like this: <a href="https://www.destroyallsoftware.com/talks/boundaries" rel="nofollow">https://www.destroyallsoftware.com/talks/boundaries</a>
Very good article. If you think about it, you will see this pattern in many places. Simply because it is the outcome of emphasizing pure functions.<p>For example, it's the heart of the virtual DOM in React. Pure functions create an entirely new (no mutation) virtual DOM, and then something at the "impure boundary" applies this to the actual, messy, mutable DOM of the browser.<p>With a little thought you can probably find several other well-known examples.
It's interesting -- this is not what I generally end up using DI for. The point of DI, a lot of the time, is to put seams into the program where you can test units of a limited size. If you don't have some way of injecting behavior, you end up having some serious trouble when you have a module that brings together the behavior of many sub-modules (how do you test it?). That's something these short code example style articles never seem to capture for me.
Two things:<p>1. This is overly simplistic. What happens if your IO and logic are by necessity interleaved? Grab X out of DB, grab Y or Z out of DB depending on X's value, etc.? The whole thing just reeks of "ideal case".<p>2. This is overly complex. All that really needs to be said here is "pull out your pure code when possible". There's nothing special about F# to enable that. The logic in "tryAcceptComposition" is just a function calling other functions; you can do that in C# or even C. The only advantage F# adds here is the piping syntax, which to me only serves to make the code more obtuse. But I guess you couldn't write a three-part series about a single "extract pure function" op.<p>(This brings up an interesting thought: ReSharper should come up with a way to let you highlight a function and extract the "obviously pure" tidbits automatically).
The key part about why dependency injection with partial application is not functional:<p>> When you inject impure operations into an F# function, that function becomes impure as well. Dependency injection makes everything impure, which explains why it isn't functional.
It seems that in the end the initial function Post(ReservationRequestDto dto) has to call the tryAcceptComposition which has its dependencies hard coded there. So how exactly this solved the issue?<p>If you pass the dependencies as parameters in the tryAcceptComposition function, the Post would have to know its dependencies and we would be back to the initial state.<p>I would like to know the whole example he showed before using this model to see how this scale for more than one function.
Nice! An alternative is to try something like SimpleMock <a href="http://deliberate-software.com/simplemock-unit-test-mocking/" rel="nofollow">http://deliberate-software.com/simplemock-unit-test-mocking/</a> which strikes a balance between useful and easy to test. Also there's examples in F# <a href="http://deliberate-software.com/f-number-unit-testing/" rel="nofollow">http://deliberate-software.com/f-number-unit-testing/</a>