.NET SDK: Strong Types vs. Modular Content

petrs@kentico.com[email protected] Eindhoven, NLMember, Administrator, Kentico Staff admin
edited February 2017 in Back-end Development

In my previous post I tried to shed some light on how we think about strongly typed models in the Deliver SDK.

I only talked about retrieving content items. The other thing that comes in response to a request to the /items/ endpoint is called "modular content".

What is modular content? Modular content is a type of field that basically allows you to link pieces of content (content items) to other content items. One "modular content" field can contain links to content items of different content types. This flexibility opens unlimited possibilities in modelling your content. On the other hand, there's no way of telling what content types will be stored in a modular content field in advance.

The questions then are:

  • How would we, developers like the API to expose this data?
  • Does a strongly-typed approach make sense here?

Currently, ContentItem exposes the following method: IEnumerable<ContentItem> GetModularContent(string element).

What if we wanted to work with strongly-typed models? Here are some options:

1) We could let the developer to cast-promote a single content item to a higher type. new ArticleModel(ContentItem item)

2) We could introduce a new method IEnumerable<T> GetModularContent(string element) where T:ContentItem, new(). But then, what should happen if there are mixed content types in the element field? Should we assume it's ok and leave the resolution up to developer?

3) We could extend no. 2 by giving the developer an option of providing a mapping between content types and strongly-typed models (a factory?). The SDK would then be able to retrieve only desired content types and instantiate their respective strongly-typed models.

What would be the best approach according to you?

Coming up next: Model generator...

Sign In or Register to comment.