.NET SDK: Strongly Typed Models

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

One of the prerequisites for some of the functionalities mentioned by @JanLenoch in his posts (e.g. re-using views) is to have an option of retrieving strongly-typed models via the Deliver SDK.

So that you could have

public class ArticleViewModel : ...
{
...
 public string Title { get; set; }
 public HtmlString BodyCopy { get; set; }
 public DateTime PostDate { get; set; }
...
}

and use @Model.BodyCopy instead of @Html.Raw(@Model.GetString("body_copy")) in your views.

We are not the only ones who see the need of this. E.g. Emmanuel Tissera has created a custom wrapper around the Deliver SDK that provides allows mapping ContentItems to strongly typed models. Check out the EmmTi.KenticoCloudConsumer.EnhancedDeliver repository on GitHub.

To retrieve the data you simply call
await DeliverClientFactory<SampleViewModel>.GetItemAsync(SampleViewModel.ItemCodeName);
and pass SampleViewModel as a type parameter.

We'd like to have the same developer experience in the Deliver SDK out of the box. For that reason, I've created a branch on GH with a proof-of-concept code. If you want, you can check out just the diff. The prototype has been created without any previous knowledge of Emmanuel's code. The fact that it's architected similarly is a pretty good confirmation of the direction we are heading towards.

In both Emmanuel's and my code it's required that models inherit a certain base type. I don't see it being a big issue. However, I'd like to hear your opinion. Do you think there are scenarios where you could benefit from being able to retrieve POCO models?
What do you think of the overall architecture?

Coming up next: Strong types vs. Modular content...

Comments

  • petrs@kentico.com[email protected] Eindhoven, NLMember, Administrator, Kentico Staff admin
    edited February 2017

    2 approaches compared:

    1) Inheriting ContentItem - advantages:

    • follows the principles of the current SDK (simpler migration path for the existing users)
    • easier/faster to implement
    • you can take advantage of the base class and use the same approach to retrieve modular content items - even if there are different types of MC stored in the same field
    • we can ship new functionality by extending the base class
    • similar concept to *Info objects in Kentico EMS

    2) POCO approach - advantages:

    • definitely cleaner
    • no dependencies

    ? we could base it on http://www.newtonsoft.com/json/help/html/SerializationAttributes.htm as we already use newtonsoft.json
    ? not sure how it would work for modular content - research required

    Learning path for users:
    In both cases, the user needs to know some implementation details to create models by hand.
    Either that he has to use json attributes or that he has to inherit from ContentItem and initialize properties. In both cases, this would be solved by having a code generator.

    My recommendation would be:
    - use the first approach
    - store value of the properties (either by setting them directly through Initialize/MapContentForType methods) or by having a backing field (possibly lazy-loaded)...so that the properties don't have to touch the underlying object every time their getter is accessed
    - the initialization should use GetElementValue rather than GetString/GetDateTime methods
    - depth of modular content should be loaded from the Filter object supplied to the DeliverClient rather than supplied by user. (the filter would have a default value of 1 which corresponds with the API defaults)
    - if it turns out people want POCO models we could always implement it

Sign In or Register to comment.