The past five years I've worked mainly on HTTP APIs, but since late last year I have a new job where I mainly work on Umbraco CMS implementations. A lot is the same, but there are also some big differences.
Technically, one of the biggest differences is the outside boundary or interface of an HTTP API versus that of a CMS implementation. For an API it is clear: its URL structure and resources are its interface to its consumers. Contrast that with a CMS: it produces pages of HTML. That is its interface, even though it looks a bit messy compared to an API.
The great thing about software design is that once you know what the interface is, you can build everything behind that interface the way you like it, given some technical limitations of course.
One of the technical limitations of an API is that you don't send a database entity over the interface, because it might expose too much data. Especially if the ORM used supports lazy loading. If you're not careful, you just might send the entire database over the line. To counter this limitation, a class is introduced that has just the properties that the interface requires. The database entity is then mapped to that class and that is sent over the line.
The above approach is often applied in CMS (or MVC) implementations as well. The controller gets the data from the database, maps it to a view model class and passes the view model to the view, which then turns the view model into HTML. I'd like to call this model the dumb view. Not because it's stupid, but because it does nothing more than processing the view model.
In my opinion the dumb view is not required in CMS implementations. First, because mapping is done twice: once for the database entity to the view model and once for the view model to HTML. Second, because exposing too much data is not a risk anymore: The view controls which data it renders, as opposed to a serializer of an API response object.
Enter the smart view: it receives the database entity directly and renders that into HTML. Mapping is done once in the view, alleviating the need for a view model and mapping layer. The smart view increases the complexity of the view slightly, but greatly decreases overall complexity, because of the skipped layers.
Care to give it a try?
Technically, one of the biggest differences is the outside boundary or interface of an HTTP API versus that of a CMS implementation. For an API it is clear: its URL structure and resources are its interface to its consumers. Contrast that with a CMS: it produces pages of HTML. That is its interface, even though it looks a bit messy compared to an API.
The great thing about software design is that once you know what the interface is, you can build everything behind that interface the way you like it, given some technical limitations of course.
One of the technical limitations of an API is that you don't send a database entity over the interface, because it might expose too much data. Especially if the ORM used supports lazy loading. If you're not careful, you just might send the entire database over the line. To counter this limitation, a class is introduced that has just the properties that the interface requires. The database entity is then mapped to that class and that is sent over the line.
The above approach is often applied in CMS (or MVC) implementations as well. The controller gets the data from the database, maps it to a view model class and passes the view model to the view, which then turns the view model into HTML. I'd like to call this model the dumb view. Not because it's stupid, but because it does nothing more than processing the view model.
In my opinion the dumb view is not required in CMS implementations. First, because mapping is done twice: once for the database entity to the view model and once for the view model to HTML. Second, because exposing too much data is not a risk anymore: The view controls which data it renders, as opposed to a serializer of an API response object.
Enter the smart view: it receives the database entity directly and renders that into HTML. Mapping is done once in the view, alleviating the need for a view model and mapping layer. The smart view increases the complexity of the view slightly, but greatly decreases overall complexity, because of the skipped layers.
Care to give it a try?