Try our conversational search powered by Generative AI!
AI OnAI Off
Reduce use of extension methods in new Order system
I was not part of the decision, but I think the point is to keep the interfaces small, so make it easier to implement a custome implementation.
All extension methods come with overload to take a dependencies which make the mocking possible.
Feb 01, 2017 13:23
Mocking frameworks will still report about "can't find method X on instance Y" since it's an extension. Mocking with a stub implementation is still possible if I wrap it in a facade.
Small interfaces are nice to have, but if a solution is so custom it actually needs a custom order repository class, it's probably never going to implement all methods anyways.
So all in all, i'd rather have a fat interface to make everything super easy, and let the very few self-implementers have a few unused methods.
Feb 01, 2017 13:37
This thread is locked and should be used for reference only.
The new Order system (ICart, ILineItem, IOrderRepository etc) is really nice in many ways, but it's still (partially) very hard to test since so much core functionality happens in extension methods. Especially those in IOrderRepositoryExtensions. I can now mock every entity due to nice use of interfaces, but if I use commonly needed extensions such as LoadOrCreateCart, I'm basically screwed. I can make a facade/wrapper around it all, and expose the extension methods as instance methods on that - but that should really be unnecessary to have in my own code.
Are there any specific reasons why so much happens as extensions, instead of as interface members along with the rest?