[This post is part of the developer's manual preview published on this blog. You can find temporary TOC here.]
Now, that we have examined the reasons behind the new architecture in Sitefinity 3.6 and that we have determined which parts of backend architecture have changed, we are going to take a high level overview of the new backend architecture. You can think of this article as a map for all the coming articles - which will talk in more detail about specific part of this “map”.
Hierarchy of Views
On the highest level of abstraction, new backend architecture is just a hierarchy of Views. View is a control which inherits from:
ViewModeControl and ViewModeUserControl base classes are identical except in the fact that ViewModeControl class inherits from CompositeControl class, while ViewModeUserControl class inherits from UserControl class.
- ViewModeControl (custom control based View) or
- ViewModeUserControl (user control based View)
Having this in mind, we know that every view can have child controls, since every CompositeControl and UserControl can. In addition to this, however, every View can have a collection of child Views or Subviews. A child View is nothing more than another control based on ViewModeControl or ViewModeUserControl (actually it is a control that implements IViewInfo interface but for the sake of simplicity let’s leave that out of the picture for now).
By overriding base class CreateViews() method, Views are able to add their subviews, and their subviews can add their own subviews in the same manner and so on.
Let’s take a look at the following diagram to see a possible architecture of any given module on the new backend architecture.
The diagram depicts nothing more than we have just explained in the previous paragraph. We have views (including the Root View) which are controls based on ViewModeControl or ViewModeUserControl. Those Views that required subviews, are overriding CreateViews method and adding their subviews. Now, to make one step toward the more practical applications of this architecture, let’s examine an actual architecture of the Generic Content module (in case you are not familiar with Generic Content module, you can find more information about it here).
If we are to juxtapose the abstract diagram and the actual diagram of Generic Content module, we can see that there are no real differences there. GenericControlPanel is the Root View, which has five subviews, namely:
Out of these five views, we notice that ContentItemsView has additional five subviews and CommentsView has additional three subviews.
- PermissionsView and
Benefits of the hierarchy
We have already mentioned the benefits of this new approach, but let’s try to see these benefits on the more concrete example of the Generic Content module. Let us say that we are building a module that will support commenting. We have the option now to add to the root view of that new module the CommentsView View and we don’t have to worry about implementing CommentsList, CommentsEdit and CommentsPreview Views, since they are below the CommentsView hierarcy and will be added automatically for us. We have the option to pick and work with the node of hierarchy that we see fit best.
Benefits of separation of concerns
With this new approach, we are also able to modify only particular parts of the module. Let us suppose that we want implement some additional user interface elements and functionality when user edits a content item. Whereas before we had to override and reimplement the whole module, we can now simply provide new implementation of the ContentItemEdit View and inject it in the existing module through ControlsConfig file.
Obviously, this approach becomes even more straightforward if we are building a new module based on Generic Content module. We would simply override CreateViews method of ContentItemsView and add our own implementation of ContentItemEdit view.
In the next article we are going to dissect the Views as building units of the new backend architecture and provide samples on implementing them.