Hi,
It sounds like we have a not-so-good design decision here - but I can't say for sure until I take a good look at our code and remember all the reasons we came to that. I might log a bug for that and will get back to you.
Your current implemetation is a good example of how you customize EPiServer to make it works for you - we - with all efforts - can't make it works for every case. But we try really hard to make sure you're able to extend our framework where you want, when you want. Your solution seems to be good - why do you need a "better" solution?
Regards.
/Q
Hi Quan and thanks for your reply! I just have a somewhat bad feeling that we're doing a "hackaround" and basically disabling part of the functionality to overcome performance issues. But then again, this isn't perhaps a normal case so I guess we can live with it. Nevertheless, it would be interesting to hear how other large b2b sites have dealt with the situation.
No, I believe that's not a "hackaround". IPriceService was introduced to let customers - in this case - you - to be able to customize/extend EPiServer Commerce to fit with your specific requirement. It's something we encourage and in your case - I would like to say "Good job!".
Regards.
/Q
Whenever ContentLoader is used for a product, it will fetch all its variations and all their prices by calling PriceService.GetCatalogEntryPrices. This means that all prices for products will be loaded, even in places where they will not be used, for example when using UrlResolver.GetUrl for a product. In effect, among other things, this means that on a category listing page, all prices for dozens of products will be loaded for no gain. The variations and prices are also loaded by the EPi framework before invoking the controller action for a product page (which we don't need in our implementation).
GetCatalogEntryPrices loads all prices for an variation - regardless of customer. Although Episerver's implementation PriceServiceDatabase uses caching to make it efficient, this still means that there will be a performance hit when listing/viewing a product whose prices are not cached.
Typically in a b2c site you might get away with this because every variation only has a small amount of prices. However, in our b2b implementation, each customer has a unique price per variation. And with 10K customers, we have more than 10K distinct prices for a variant (adding staffling on top of it). Caching all of these prices for all variations (more than 30K) takes up an insane amount of memory and loading all the prices from the database (either because there is no caching or because the cache entries for the variations have expired) makes the site very slow.
Our current solution is to make our custom IPriceService implementation return no prices in its GetCatalogEntryPrices() method, which at least hides the problem (when we actually want the prices we use the GetPrices() method in that interface).
Does anybody have a better idea of how to handle the problem?