Change default implementation

The default implementation for IOrderRepository is architected so that it does not need to be replaced to provide custom implementations for different order types. Instead, register implementations for ICartProvider, IPurchaseOrderProvider, and IPaymentPlanProvider to change the behavior of IOrderRepository.

Listen to and act on order repository events.

Change the default implementation of loading and persistence of shopping carts.

Change the default implementation of loading and persistence of purchase orders.

Change the default implementation of loading and persistence of payment plans.

Create implementations of the order system object abstractions. You almost certainly need to change the default implementation if you create a custom order provider, which uses different objects for persistence.

Create sub-components  of an order group object abstraction. Each builder is registered to create sub-components for specified types of IOrderGroup. If you create a custom order group, you might need to create a custom order group builder as well, which is registered for the custom group type.

Determine a shipment's default warehouse. You need to change the default implementation if you have multiple fulfillment warehouses, because the default implementation only supports one fulfillment warehouse.

Adjust inventory. You need to change the default implementation if you integrate with another system for inventory checks.

Determine if a line item is valid in terms of active status and availability dates on the entry itself as well as the catalog. You need to change the default implementation if you have other criteria which determine if a line item is valid.

Get the currently-placed price for an line item, and update it if necessary. You need to change the default implementation if you have additional pricing rules outside of what is implemented in the configured pricing provider.