Quan Mai
Jan 17, 2018
  5141
(9 votes)

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!

Jan 17, 2018

Comments

Please login to comment.
Latest blogs
Catalog Traversal in Action. Part 2: Real-World Scheduled Job Patterns

In my previous post, I showed how to build a memory-efficient catalog traversal service for Optimizely Commerce. The service uses streaming to...

Stanisław Szołkowski | Feb 24, 2026 |

Resource Editor - A localization management tool for Optimizely CMS

If you have worked with Optimizely CMS for any amount of time you know that managing localization through XML files can be tedious. Content type...

Per Nergård (MVP) | Feb 23, 2026

Storing JSON in a property the efficient way

Here is a little-known trick to store and retrieve JSON property data more efficiently.

Stefan Holm Olsen | Feb 23, 2026 |

Development Agent V2: From Element Tweaks to Full Page Experiences

The Development Agent in Web Experimentation just got a major upgrade - moving from single-element edits to page-level changes with design system...

Hristo Bakalov | Feb 23, 2026 |