Looking over the definition of the Unit of Work pattern it seems very much like what a programmer would get if they implemented a Monad such as an IO or Transaction Monad. What makes the unit of work concept fundamentally different from the use of a Monad? Assume that we are working in a language that has enough power to implement most common Monads fully and can implement a unit of work pattern similar to what you may find in Java or C#, especially one with a type system such as Scala’s or Haskell’s.
If one can be chosen over the other what are the pros and cons of each approach?
4
Your question is a little odd, sort of like asking why you need the unit of work pattern when you could just use objects. Monads are more fundamental than your question implies. You can use a monad as part of the implementation of the unit of work pattern, but that’s not a sufficient description of the solution. You would also need to describe which monad to use, the type parameters used, how to initialize it, how to implement a step, and what to do with the result.
A transaction monad indeed looks like it might be a relatively good building block to implement this pattern, but perhaps a new monad specifically created and tailored for implementing unit of work would be cleaner.
However, part of the benefit of the unit of work pattern is that it helps gather database updates from scattered places in your code. Monads have the annoying property that they want to be already gathered. If you have to gather your database update code into one place anyway, there might be a simpler way to aggregate it.
3