In a previous blog post (https://deliverystack.net/2020/07/23/expose-entry-json-from-entry-model/) I mentioned that I’m using a repository class to abstract access to the CMS, in my case Contentstack (though I have developed partial prototypes for Contentful, Kentico, and elastic). What I mean by a repository is just an abstraction layer on top of the CMS or other system.
A repository implementation can provide the following:
- A repository abstracts CMS implementation from other projects, including connection configuration. Consumers simply pass identifiers or queries and receive Entry Models of a predefined or requested type.
- The repository can cache JSON retrieved from upstream systems including CMS. Importantly, the repository can also manage cache eviction and clearing after publication (consider JSON, Entry Models, ASP.NET output, and any other caches), typically using CMS webhooks and/or synchronization APIs.
- The repository can abstract multiple sources (in Contentstack, multiple Stacks) from multiple providers (vendors and internal systems) of various types (CMS repositories, search indexes, product information management systems, inventory management systems, and otherwise). If the query or Entry identifier includes a provider identifier, designates a Content Type associated with a provider, or otherwise indicates the source system to access, retrieve the Entry from the appropriate provider, otherwise retrieve the Entry from the default provider.
- Identifiers can be Content Types with or without UIDs, URLs, product identifiers, or anything else, and can include language, version, or other attributes to match (or use separate repositories for separate languages).
- Implementations can experiment and evaluate performance with different techniques such as preloading all, partial, or no data with content delivery APIs, sync APIs, GraphQL, or directly from a search index.
- A repository can instantiate Entry Models with data from multiple repositories, for instance pulling marketing content from CMS, product content from a product information system, and inventory data from an inventory management system.
- If the repository is threadsafe, you can register the repository with dependency injection as a singleton to avoid multiple instantiations (important if caches are in its memory but not static). But then again, your cache should be separate from your repository.
- A repository easily supports multiple local caching infrastructure options.
2 thoughts on “.NET Repository Pattern for Headless (CMS)”