1) would basically be a simulation approach like ERP / SAP do it sometimes. That's very expensive - eventually acceptable, depending on the traffic on details pages. Depending on the complexity of a user context determining the promotion, the simulation could be cached.
As the promotion logic is made for complex rules / contexts around a cart/order to determine if a promotion applies it seems to me that it's significant effort to decouple it from cart/order.
So the solution 2) doesn't seem reasonable as you'd either need to replace or duplicate the calculation logic.
A third solution could be to base your price promotion on normal discounts instead of promotions as they are global and part of the product price finding process.
You could define your own derivate of discount that eventually has some more context (beyond product / customer / time etc.) to it, giving it some features of promotions.
Alternatively addition PriceRows with additional restrictions on them.
For both you need to replace / append the price finding logic to include your new restrictions.
This limits the possibilities versus promotions, but does not require a cart or an order and should be less effort than 2) and is surely less expensive per call than 1).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.