CartHelper is dead, long live IOrderRepository
As a framework provider, we take backward compatibilities seriously, and we keep supporting public APIs as long as it makes senses. If we can improve our framework by changing the internal implementation without having to change the singatures, we'll go with that.
But sometimes, to improve, we need to leave old APIs behind.
CartHelper is one of the oldest APIs in Episerver Commerce framework, and while it's convenient to use, it has several major drawbacks:
- It ties to other "legacy" APIs, such as Entry, which are less then elegant to use .
- It is tightly coupled with the concrete implementation (Cart, OrderForm, etc.), so it's impossible to switch to the new serializable cart mode for better performance.
- It is hard, if not impossible to unit test.
- It always creates new carts if none exists, even if you don't really need them
We already introduced the new abstraction APIs - IOrderRepository, IOrderGroup, ICart... from Commerce 9.19, and fully recommend to use those new APIs to handle carts and orders. New abstraction APIs solves all of the problems above, and yet you have nicer, better looking code. There is no reason to keep using CartHelper now.
In Commerce 11.6.1, we push the recommendation further. CartHelper is now obsoleted and will be removed in a forseeable future - it will be removed in the first major release after Jan 2019.
As always, you should move away from obsoleted APIs, instead of ignoring the warnings with #pragma directives. For CartHelper, the migration path is clear, IOrderRepository is simply the better, future-proof way to go.
CartHelper is dead, long live IOrderRepository!
Comments