It can be pretty confusing for new Commerce developers to understand how to work effectively with entries in Commerce. There are many things which represent the same concepts, however they are different and their APIs are not compatible. So which is which and what should you use?
Which is which
- CatalogEntryDto is the DataSet to represent one or more entries (CatalogEntryDto can of course be empty). Beside the basic information like Name, Code, or MetaClassId, depends on how did you load it, a CatalogEntryDto can contain information about the assets, the associations or the variations (you can specify what to load by using CatalogEntryResponseGroup parameter. CatalogEntryDto, however, does not contain information of the metadata system of an entry – for example, if you add a metafield named “Description” to your entry metaclass – that is not available in a CatalogEntryDto.
CatalogEntryDto can be loaded or saved by ICatalogSystem methods.
- A MetaObject represents the “attributes” of an entry – so if you want to work with the Description metafield above – you’ll need to load the MetaObject and access it via metaObject[“Description”]. MetaObject can be both loaded and saved via MetaDataPlus APIs.
- Entry, and its collection, Entries, are readonly object to represent an entry (or multiple entries), along with all of its attributes (accessible via ItemAttributes), even prices and inventory information – so it’s the most complex object of all. Entry was supposed to be the POCO approach for entry, but you can’t extend it in any way, and it cannot be saved.
- EntryContentBase is the representation of entry in new Content system – You hardly work with it directly, but with its derived classes – ProductContent, VariationContent, or even more frequently, with the content types you defined in your solution – such as MirrorlessCameraProductContent, DLRCameraProductContent.
What to use
CatalogEntryDto + MetaObject are the “traditional” combination. They are still working “well” today, but with some limitations – such as inferior support for versions and limited compile time checking.
EntryContentBase and its derived classes are the new way forward – they are superior in many ways, compared to CatalogEntryDto + MetaObject, as I already mentioned here . However, there is one place where CatalogEntryDto still works better than EntryContentBase – batch processing, using Catalog Search APIs . Simply put, if you start a new Episerver Commerce project today, you should be using new content APIs. If you have a solution which are still using CatalogEntryDto + MetaObject, then plan to update your code to the new content APIs as soon as you have chance. That’s a big investment, yes, but it will pay off in long term: You have better code, saving time for both reading and extending in the future. The code with strongly typed content types is also more robust as compile time checking will save you some headaches from mismatched types and names.
What’s about Entry/Entries? Out of these three, they are the worst: they are big, slow to load, and are not cached efficiently (as they are not used by other parts of the system). They are used in mostly two places:
- If you are using CartHelper, then you have to use Entry. This is one of the reasons why you should move to the new order abstraction system instead – to add items to cart, you only need the entry’s code, which is faster, easier and use less memory than the Entry.
- If you are using SearchFilterHelper, then the result of the search is Entries:
public virtual Entries SearchEntries(CatalogEntrySearchCriteria criteria, out int count, CatalogEntryResponseGroup responseGroup, bool cacheResults, TimeSpan cacheTimeout)
This is not needed, and less than optimized, if you use SearchManager directly, you can get back an array of entry ids, which you can use ReferenceConverter and IContentLoader to load the contents of search result. Again – better code, and better performance as well because the contents are reused by other parts of the system, so their cache will be reused.
If you are using Entry/Entries – it’s worth the time to consider moving away from it. We have better alternative: better performance, smaller memory footprint, and most importantly, better, more solid code.
