Not Mandatory in MVC

This content originally appeared on DEV Community and was authored by Elanat Framework

The MVC (Model–View–Controller) architecture was first introduced in the 1970s by Trygve Reenskaug at Xerox PARC, when he was working on the Smalltalk language. The main goal of this architecture was to separate the data logic (model), the user interface (view), and the control of user interactions (controller) to make software development easier, maintainable, and testable. The pattern quickly caught on in the software development world and was later extended to various frameworks such as Ruby on Rails, Django, and ASP.NET MVC.

In the world of web development, the Model–View–Controller (MVC) pattern has long been hailed as the gold standard for organizing code. It provides a clean separation of concerns and makes applications easier to manage and scale. But following the traditional MVC pattern exactly isn’t right for every part of the project! The traditional MVC pattern is based on a “controller first” structure, which, for all its benefits, has its drawbacks.

Disadvantages of the Traditional “Controller-First MVC” Architecture

The traditional MVC architecture is based on the assumption that each request must first be processed by a controller. The controller then receives data from the model and finally selects an appropriate view to display the information. This “Controller-First” thinking model, although effective for complex and large applications, in many cases causes:

• Additional Code (Boilerplate): To display a simple and static page, the developer is forced to create a controller and the corresponding action. This leads to the generation of redundant and unnecessary code that makes it more difficult to maintain.
• Tight Coupling: In this approach, the view is strongly dependent on the controller. This dependency prevents the view from acting independently or being reused without depending on a specific controller.
• Complex Routes: Routing in this pattern is often defined centrally in a configuration file, which can be challenging to understand and manage in large projects. This approach does not establish a direct relationship between the physical path of files and the virtual path of URLs.

The new “View-First MVC” approach

The “View-First MVC” architecture is a paradigm shift from “controller-centric” to “View-Centric”. In this model, the view is considered the starting point. This new approach, implemented by Elanat in the CodeBehind framework, not only retains the advantages of traditional MVC, but also solves its problems and provides more flexibility.

Independent and flexible View

In this approach, the view is completely independent. Specifying a controller or model for a view is simply a declaration, not a hard-wired one. This means that a view can run independently without any model or controller. Dependencies are declared explicitly in the view file itself and can be easily removed when not needed. This allows developers to create simple, static pages more quickly without having to go through the full MVC scaffolding.

Key Benefits of View-First MVC

• Reduced Redundancy: Developers can eliminate unnecessary layers such as the model or controller. This is especially useful for simple pages that only display near-static content. Less code means fewer bugs and easier maintenance.
• Flexibility: In this approach, the current view can be discarded and a new view can be loaded. This new view can also contain its own controller and model definition; as a result, the corresponding controller will also be executed. It is also possible to call another controller from within the current controller.
• High Modularity and Encapsulation: Each part of MVC (model, view, and controller) can be considered a separate, independent module. This logical separation is stronger than in the Controller-First architecture, making components easy to move and reuse (plug-and-play).
• Easier Testability: Since each MVC component is isolated, it is easier to perform unit testing for each part. Dependencies are explicitly declared and managed instead of being hidden in a centralized system.
• Intuitive Routing: The fact that the physical path of the view file and its virtual URL path are the same provides a standard that is understandable and intuitive for developers. This approach makes it easier to understand the project structure and makes the routing process more transparent.

• Hybrid Approach: Teams can adopt a hybrid approach based on the needs of the project. That is, in some parts they use “View-First MVC” for simplicity and speed, and in other parts they use full MVC for more complex logic.

• Easy to Learn: This approach is very understandable for beginners and makes the MVC pattern easy to understand. The training can start with the View section so that learners first get familiar with how to display data. Then, using simple examples on the same View page, the need for the Controller and Model can be easily explained and the relationship between MVC components can be taught gradually and concretely.

How to configure “View-First MVC” in the CodeBehind framework

Program.cs

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

SetCodeBehind.CodeBehindCompiler.Initialization();

app.UseCodeBehind();

app.Run();

In this approach, we can use the only-view development pattern.

Example:

@page
@{
    Random rand = new Random();
}
<h1>Random value: @rand.Next(1000000)</h1>

The above example shows a View page that is called without the need for a Controller.

As we said: In this approach, the physical path of the view file and its virtual URL path are the same. However: In order to achieve full compatibility with search engines (SEO Friendly) at the highest level, Elanat has added advanced features such as using sections and removing file extensions (such as aspx) in the view in the CodeBehind framework.

Example:

Enable file extension removal

To remove the .aspx extension from addresses and convert them to directory-like paths, simply enable the following option in the options.ini file:

options.ini

...
rewrite_aspx_file_to_directory=true
...

Examples of optimized URLs

Enable section in View

By defining sections in the view file, you can dynamically manage multi-part URLs. To enable this feature, simply use the following command in the view file (e.g. news.aspx):

news.aspx

@page
+@section
@controller NewsController
...

Examples of multi-part URLs

example.com/news/section0/section1/section2/

example.com/news/sport/soocer/world-cup/

NewsController

using CodeBehind;

public partial class NewsController: CodeBehindController
{
    public void PageLoad(HttpContext context)
    {   
        WriteLine(Section.GetValue(0)); // First section
        WriteLine(Section.GetValue(1)); // Second section
        WriteLine(Section.GetValue(2)); // Third section
    }
}

Output for different routes

These capabilities allow developers to create readable, indexable, and fully SEO-friendly URL paths without the need for complex configuration.

Note
The “View-First MVC” approach was first introduced by Mohammad Rabie (founder of Elanat) in the CodeBehind framework. This approach is not only View-Centric, but also considers the Controller optional and removable. We did extensive research to check whether this approach has been used before in other patents, articles or frameworks, but we did not reach any results. However, at Elanat, we do not claim to have invented or invented this approach for the first time; but we can confidently state that “View-First MVC” is a more advanced and transformative architecture than the traditional MVC architecture.

Conclusion

The “View-First MVC” approach implemented in the CodeBehind framework provides a flexible and efficient solution for web development. This approach fosters creativity, speed, and simplicity in development by giving developers the freedom to choose the components they need on each page, without being forced to follow a strict “Controller-First MVC” pattern. This model proves that to have a powerful architecture, it is not necessary to adhere to all the components of a pattern. Elanat has completely redefined the traditional MVC structure.

Related links

CodeBehind on GitHub:
https://github.com/elanatframework/Code_behind

Get CodeBehind from NuGet:
https://www.nuget.org/packages/CodeBehind/

CodeBehind page:
https://elanat.net/page_content/code_behind

This content originally appeared on DEV Community and was authored by Elanat Framework