DEV Community

Cover image for Xperience Community: Content Repositories
Victor Hugo Garcia
Victor Hugo Garcia

Posted on

Xperience Community: Content Repositories

#dotnet #kentico #xperience

If you have been building with Xperience by Kentico, you are probably familiar with the repetitive ceremony around fetching web page content: URL resolution, language detection, caching, null guards. It is the kind of code you write once per project and then paste — slightly modified — into the next one.

The Xperience Community: Content Repository package was built to centralize exactly that kind of logic. And with version 1.0.2, it gets a meaningful new addition: the WebPageRepository.

What's New in v1.0.2

This release ships two things:

  • IWebPageRepository and WebPageRepository — a new repository for resolving web page URLs by GUID, with built-in language awareness and caching.
  • Kentico package upgrades — all Kentico dependencies bumped to 31.2.0.

The web page repository is small in surface area but fills a real gap. It gives you a single, safe place to resolve a WebPageUrl from a GUID, handles language fallbacks automatically, and caches results intelligently so you're not hitting the database on every request.

Installation

Add the package via the .NET CLI:

dotnet add package XperienceCommunity.ContentRepository
Enter fullscreen mode Exit fullscreen mode

Then register all repositories in your Program.cs:

services.AddXperienceContentRepositories();
Enter fullscreen mode Exit fullscreen mode

That's it. IWebPageRepository is now registered in DI and ready to use.

The WebPageRepository

The new repository exposes a single, focused method:

public interface IWebPageRepository
{
    Task<WebPageUrl?> GetUrlByGuid(Guid webPageGuid, string? languageName = null);
}
Enter fullscreen mode Exit fullscreen mode

Under the hood, WebPageRepository wires together three Kentico services — IWebPageUrlRetriever, IPreferredLanguageRetriever, and IProgressiveCache — so you do not have to.

Here is what the implementation does for you:

  • GUID guard — returns null immediately if the GUID is empty, avoiding pointless lookups.
  • Language resolution — if no language is passed, it falls back to the current preferred language via IPreferredLanguageRetriever.
  • Progressive caching — caches the resolved URL for 60 minutes, scoped to the GUID and language. Cache is invalidated via the webpageitem|byguid|{guid} dependency, so stale URLs are never served after a content update.
  • Graceful error handling — if URL retrieval fails for any reason (page doesn't exist, routing misconfiguration), it returns null and skips caching the failed result.

For the full implementation, check the repository on GitHub.

Usage

You can access it directly through DI or via the centralized ContentRepositories accessor:

// Via direct injection
public class MyService(IWebPageRepository webPageRepository)
{
    public async Task<string?> GetPageUrl(Guid pageGuid)
    {
        var url = await webPageRepository.GetUrlByGuid(pageGuid);
        return url?.RelativePath;
    }
}
Enter fullscreen mode Exit fullscreen mode 
// Via ContentRepositories accessor
public class MyOtherService(ContentRepositories repos)
{
    public async Task<string?> GetPageUrl(Guid pageGuid)
    {
        var repo = repos.GetWebPageRepository();
        var url = await repo.GetUrlByGuid(pageGuid);
        return url?.RelativePath;
    }
}
Enter fullscreen mode Exit fullscreen mode

You can also pass a language explicitly when you need to resolve a URL for a specific locale rather than the current preferred language:

var url = await webPageRepository.GetUrlByGuid(pageGuid, languageName: "es");
Enter fullscreen mode Exit fullscreen mode

Why This Matters

URL resolution from a GUID might sound trivial, but it is a frequent request in real Xperience projects — especially when building navigation menus, breadcrumbs, related content links, or any component that stores references to other pages by GUID rather than by full path.

Without something like this, you typically end up either writing the caching boilerplate yourself for each use case, or skipping caching altogether and accepting the performance cost. The WebPageRepository solves that cleanly in one place.

What's Already in the Package

The WebPageRepository joins an already capable set of repositories. A quick summary of what the package covers:

  • IPageTypeRepository<T> — query web page content types by ID, GUID, path, taxonomy tag, or custom where conditions.
  • IContentTypeRepository<T> — retrieve reusable content items with pagination, smart folder support, and multi-type queries.
  • IMediaFileRepository — fetch media files by GUID or from asset related items, with caching included.
  • ICacheDependencyBuilder — a utility for assembling cache dependencies consistently across your project.
  • ContentRepositories — a centralized accessor that provides all repositories through a single injected service.

Conclusion

Version 1.0.2 of Xperience Community: Content Repository is a focused update — a new repository that handles one common task well, paired with a dependency upgrade to Kentico 31.2.0. If you are already using the package, updating is straightforward. If you have not tried it yet, this is a good moment to add it to your toolbox.

The NuGet package is available at nuget.org/packages/XperienceCommunity.ContentRepository, and the full source is on GitHub.

Follow me on social:

Top comments (0)