Strong Types Explained - Why the Runtime Typing

JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin
edited April 2017 in Back-end Development

In this short series of articles, we'll explain one of the greatest key enhancements in our Delivery .NET SDK: the strong types.

Contents:

Automatic Typing at Runtime

Let's take a look at what automatic runtime typing is, why we've implemented it and how you can use it.

Why

Mainly because of MVC. Back in 2009, the ASP.NET MVC 2 brought a very robust, yet simple and flexible feature called Display templates (and Editor templates, to be precise). You can read more about it in one of the MVC author's blogpost or in a short excerpt in my recent article.

Templates allow the developer to define markup (visuals) for a .NET type once and use it throughout the whole MVC app automatically (unless other visuals were selected explicitly).

The beauty of templates really shines in a situation when the MVC app obtains a collection of items of various types from the data store. In this situation, the developer does not have to care about defining the types of items and selecting templates. As long as there is a template defined for a type in the app, MVC runtime recognizes the type and renders the proper markup automatically.

But, in order for MVC to be able to select a proper template, the collection of content items cannot be typed to just one type.

To get several content items of various types, you cannot call:

var itemsOfVariousTypes = deliveryClient.GetItemsAsync<Brewer>(new InFilter("system.type", "brewer", "coffee"));

Moreover, there is another situation where it is not desired to state the type upfront: modular content.

You probably know that content items can be aggregated into another content item via a modular content element. In the Draft UI, users can assign multiple items of various types to that element. The items can fluctuate over time, right according to the edits that the business users do.

The situation with modular content can be demonstrated on a fictional Article type. The following is what MVC needs. In the ModularContentField property, the individual collection items need to be strongly typed:

var article = new Article
{
    Perex = "Lorem ipsum dolor sit <em>amet</em>.",
    TeaserImageUri = "http://example.com/image.png",
    BodyCopy = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",
    ModularContentField = new List<object>
    {
        new Comment { ItemGuid = Guid.NewGuid(), Person = "John Doe", Text = "I don't agree with the article!" },
        new Comment { ItemGuid = Guid.NewGuid(), Person = "Jane Doe", Text = "I fully agree with with you!" },
        new Review { ItemGuid = Guid.NewGuid(), Rating = 10, Reviewer = "Jan Lenoch", ReviewText = "Great article. Informative, easy to understand." }
    }
}

The items in the ModularContentField collection can be of whatever type, but they need to be strongly typed at the same time.

And this is exactly what the automatic runtime typing brings to the table. With runtime typing, the app retrieves data properly typed, even though the MVC developer had not specified a type of collection items upfront.

Why Not to Use Dynamic

The dynamic type is a great addition to the otherwise static .NET ecosystem. You can declare data as dynamic without knowing which specific members of what type it will contain at runtime. When the app retrieves some specific data, the DLR performs a discovery of all members. The only obvious difference from using static types is that references to non-existent properties result in a runtime exception instead of compiler errors.

Originally, we've been thinking about using dynamic. But the problem is that it produces anonymous (unknown) types. Like so:

var article = new Article
{
    Perex = "Lorem ipsum dolor sit <em>amet</em>.",
    TeaserImageUri = "http://example.com/image.png",
    BodyCopy = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",
    ModularContentField = new List<object>
    {
        new { ItemGuid = Guid.NewGuid(), Person = "John Doe", Text = "I don't agree with the article!" },
        new { ItemGuid = Guid.NewGuid(), Person = "Jane Doe", Text = "I fully agree with with you!" },
        new { ItemGuid = Guid.NewGuid(), Rating = 10, Reviewer = "Jan Lenoch", ReviewText = "Great article. Informative, easy to understand." }
    }
}

(The difference can be seen in the ModularContentField property. The collection items miss their type qualifiers.)

With anonymous or otherwise unknown types, MVC cannot determine the template automatically. That's why we've implemented the runtime typing.

Wrapping Up

In this part of the series, we've gone through why we had implemented the runtime typing. You now know that it allows seamless and flexible rendering of content in MVC. We've also covered what the difference from dynamic is and what the key benefit of runtime typing against dynamic.

What about you? Did you miss anything in the article? Was it easy to understand? Let us know!

Soon, we'll move onto the part 5 to see how you can use runtime typing.

Tagged:
Sign In or Register to comment.