You can use Block Model classes to model the different types of blocks that can appear in a Contentstack Modular Blocks Field as strongly-typed objects.
Block Model classes are exactly like Entry Models: Plain Old CLR Objects (POCOs) with properties that expose data deserialized from JSON that is part of an Entry. Beyond type inheritance, the main difference between a Block Model and an Entry Model is that a Block Model class represents a single type of block in a Modular Blocks Field where an Entry Model represents an Entry that can contain any number of Modular Blocks Fields.
For each Modular Blocks Field, the Entry Model can contain a property named after the Modular Blocks Field that exposes a list of the base type of the Block Model classes that represent the types of blocks that can appear in that Field.
For example, if a Modular Blocks Field can contain one type of block that contains a DateTime and a string and another type of block that contains a dropdown list that you can model with a string, you need three classes: a base class for the Block Models classes that model the types of blocks that can appear in the Modular Block Field (where that base class could model fields common to all types of blocks that can appear in the Field) and a Block Model class for each type of block. The Entry Model exposes a list property of the base class named after the Field.
So just as with Entry Models, modeling and even maintaining Block Model classes is trivial, including adding new types of blocks to an existing Modular Blocks Field. There is one significant complication. How should deserialization from JSON determine which type of Block Model to instantiate? One solution is to define an enum that contains a value for each type of block, where each Block Model exposes a property of that enum type with a different value that matches the identifier for that type of block as it appears in the JSON. You need a JsonConverter (https://www.newtonsoft.com/json/help/html/CustomJsonConverter.htm) so that deserialization can create objects as appropriate.
The Contentstack .NET Model Generator (https://www.contentstack.com/docs/developers/dot-net/contentstack-net-model-generator/) can generate all the required classes for you and give you examples from which you can learn to do this yourself. Once you have modeled one Modular Blocks Field, you will see that it is much easier than it sounds and that adding types of blocks is a snap…pun intended.
Then you will face the issue that you need to register the JsonConverter before deserialization. I intend to post working code that uses generics instead of creating a JsonConverter for each Modular Blocks Fields but it only works if your properties that model the Modular Blocks Field can inherit from a common base class (which should NOT be in the Contentstack .NET SDK).
In general, this model seems to fit .NET very well, and does not violate my principles as an architect. In fact, centralizing the logic in JsonConverters seems to be very appropriate.
Block Models can have a string property that hard-codes the name of a partial view to which you can pass the Block Model. You could use a dropdown list Field in the CMS to expose that property and let the user select a view from a list of options. You can do the same thing at the Entry Model level with a simple String property.
3 thoughts on “How Contentstack Modular Blocks Fit .NET Core”