Why Isn’t This In the .NET SDK?

It is very valid for .NET Core developers working with headless CMS to ask why some of the code suggested in this blog does not appear in the SDK, including at least the following.

• .NET types to expose more functionality around Field Types, for example converting Markdown to Markup or wrapping strings with HtmlString to avoid redundant HTML encoding or worse, @Html.Raw() in views (https://kevinchalet.com/2018/01/09/why-you-should-never-use-html-raw-in-your-razor-views/).
• An attribute (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/attributes/) to map Entry Models to Content Types and/or vice-versa.
• An abstract generic base class to simplify Contentstack Modular Blocks implementations including JsonConverter registration (https://deliverystack.net/2020/07/22/how-contentstack-modular-blocks-fit-net-core/).

To the extent possible, Entry Models should have no dependence on or awareness of the CMS, its .NET SDK, its RESTful API, or its JSON formats. Use the SDK to retrieve and deserialize from JSON to your Entry Models, possibly using the vendor’s default Entry Model class as an intermediary between the CMS and your Entry Models.

Most enhancements relevant to .NET would likely belong in the vendor’s model generators rather than their SDKs because the generated classes belong in a project that does not depend on the CMS .NET SDK. For example, model generators could model inheritance patterns in Content Types as class hierarchies, use the generic approach for Modular Blocks, create classes to model the various types of fields (including any required conversions that do not depend on vendor SDKs), and so forth.

Another potential enhancement could involve API coverage. The SDKs may not cover all available RESTful APIs. It is not much work to call those services directly, but it would be nice to use the existing infrastructure in the SDKs, if possible.