Interface Model Implementation Map

It's generally a good idea to keep your concerns separate. Your Controller or View Component should not need to perform database lookups or other advanced logic, that should be kept separate. Instead, it should use Interfaces to retrieve the data it needs to build it's View model.

When creating that functionality, this is the design pattern the baseline implements.

We'll use the Tab Parent Feature in our example:

1. Create an Interface / Method to what you need

• This interface should be found in the MVC.Models
• It should return a model also from MVC.Models, so it will be Xperience Agnostic.
• Example, IPageContextRepository and ITabRepository return PageIdentity and TabParentItem/TabItem respectively.

2. Implement these interfaces in the MVC.Libraries

• use the CacheDependencyKeysBuilder to build any dependencies.
• use Xperience's APIs, caching the data appropriately (either through the IPageRetriever or IProgressiveCache), passing the CacheDependencyKeysBuilder's dependencies to it.
• convert Xperience model to the generic model, either manually or through a tool like AutoFac
• Example, see IPageContextRetriever.GetPageAsync(string path)

3. In your Controller/ViewComponent, use that model to build your View Model and render

MVC Caching

The tool MVCCaching provides some helpers for your implementation:

1. the ICacheDependenciesStore stores dependencies keys, which when coupled with ICacheDependenciesScope.Begin() and ICacheDependenciesScope.End() you can pass all the dependencies for any API calls into the <cache> tag's <cache-dependency cache-keys="@CacheScope.End()" />. This enables you to ensure cached content is cleared if the data driving it is changes in Xperience.

• See the Begin, the store, and the cache-dependency end as an example

2. MVC Caching also provides with IRepository / IService interfaces which when you decorate your Interfaces with them, they will automatically get injected into the Service Collection.

Other considerations

The data retrieval model that is used is pretty standard MVC, however, Sean Wright has written multiple articles describing the design pattern he uses, which is to have each operation / call be its own class, that receives parameters and returns the results. Each also has mapping logic and cache key generation. Read about them on his Database Query Caching Pattern for handling the caching side of things. He has a Github and NuGet package on this that he has been working on, and describes how to leverage this model.