When working with plain CMS projects, you're mostly using the IContentLoader or IContentRepository interfaces to deal with content. When you add Commerce to your project, you will still be using these, but displaying a product with all its properties requires quite a bit more. Since you're now using MVC and proper IOC and dependency injections (of course you are!), here's a list of a few key services Commerce provides you with, that you can include in controllers or your own service classes:

  • ICurrentMarket and IMarketService lets you deal with the current market or other markets. This is relevant for getting prices, taxes and more.
  • ILinksRepository - lets you find relations between catalog nodes and entries. Remember that a catalog entry may have multiple parents, or be related to other entries.
  • IWarehouseRepository - get your warehouse data from this. Relevant if you are dealing with multiple warehouses.
  • IWarehouseInventoryService and IInventoryService - handle inventory. It might be nice to tell your users that the product is in stock.
  • IPriceDetailService and IPriceService provide prices for catalog entries.
  • ReferenceConverter lets you convert between a product's product code and proper content references.

In addition to these, there are (currently) a few important classes still implemented the old fashioned way which you might need: PaymentManager, ShippingManager and TaxManager.

Beyond PageData and Blocks!

In Commerce, you will be dealing with a few new "baseline entities". In the CMS you have PageData, MediaData and BlockData. Now you will also have ProductContent, VariationContent, BaseNodeCatalogData and more to represent your different products and categories.

If you're going to be displaying i.e. multiple different product types in the same lists and treating them equally in some context, you will need to create clever inheritance hierarchies and interfaces to group them up. So basically just as in plain CMS projects, but with more variety in the base types you have. Especially menus and such that will include multiple types might become harder to implement. Expect to spend more time on trivialities like content lists or section pages.

Size matters

We all know this already. A Commerce Project will generally be larger than normal CMS projects. It will be integrated with more external services, and it will most likely contain more business logic than plain CMS sites to be dealt with.

Do keep this in mind - doubling the size of the code base, will probably more than double its complexity. In the long run, this will make even small changes noticeably slower to implement and test thoroughly. As these sites directly generate revenue for your customers, proper testing is an absolute must-have.

Keeping up to date

Now that EPiServer's continuously rolling out updates, you should set aside a few hours during your project simply to keep everything up to date. There are neat NuGet packages for both the CMS, Commerce and the Commerce Manager, but just upgrading and dealing with migrations, running database updates etc along the way does steal time. Staying up to date ensures you always have the latest fixes and features, and especially Commerce is getting a lot of love in every patch.

This blog post is part of the series EPiServer Commerce project essentials which will give you a few tips on how to plan your projects.