What is MVC
According to the definition of MVC architecture, MVC is a design pattern used to separate user interface (view), data (model) and application logic (controller). In this pattern, the controller connects the model and the view.
The MVC structure of most back-end frameworks is that the controller must be configured in the route. In this type of architecture, all requests reach the route, and then the route calls the controller based on the text pattern.
Laravel, Ruby on Rails and ASP.NET Core frameworks are the most famous web frameworks where the controller must be configured in the route.
The image above shows the MVC architecture in Ruby On Rails, which was added from the following page:
https://www.bogotobogo.com/RubyOnRails/RubyOnRails_Model_View_Controller_MVC.php
It is interesting that the Microsoft company soon realized the defects of the controller configuration architecture in the root and introduced an alternative to MVC in .NET by introducing Razor Pages. Of course, the Elanat team did better than Microsoft and took a revolutionary initiative by removing the root in the MVC architecture and transformed the MVC architecture.
Disadvantages of configuring the controller in route
In this article, we first criticize the MVC architecture of configuring the controller in the route, then we introduce the MVC architecture without the need to configure the controller in the route in the CodeBehind framework.
Learning is hard for beginners
Complicated to use, hard to learn, these are the words used for MVC architecture. Even if beginners understand the hard concept of MVC, still configuring controller in route is challenging for them. In addition to the difficulty of creating the pattern string in the route, it is difficult to create methods that call the view and model in the controller; the reason for this is that in this type of architecture (configuration of the controller in route), the structure of the controller is necessarily complicated.
Usually, the development of web applications is very simple; you just need to add a script executable file in a physical path, then the url path will execute the script executable file according to the path.
Example:
Physical file path
root/page/contact.php
Execution path in url
example.com/page/contact.php
The presence of the physical script file in the root of the program makes the program understandable, so it is very easy for beginners to understand this structure. However, a system created with the controller configuration in the path does not actually represent anything and is only an abstract view.
Reduced modularity
It becomes very difficult to support the module (modularity). If you configure the controller in the route, how do you want to support modules that are MVC themselves? For this, you must configure the new controller module in route; in this case, you have to touch the codes of the route section, and this is no longer modular and is called system development. How can normal users add new module controller in route?
This is very bad for non-interpreted frameworks and non-interpreted programming languages, because they will need to be recompiled!
Suppose you have created a content management system. You have created this system based on MVC and specifically with the configuration of the controller in the route.
You want to create 4 separate modules of the system as well (slideshow, gallery, contact us and user information modules). Each of these modules has several controllers. Even if each module has only one controller on one route, the route string can be written dynamically, but there is still a need to consider complicated things such as adding middleware.
It is possible to add a dynamic controller and disable the possibility of creating a module with the controller; this will also close your hand to create powerful modules and the created module will have only one view.
Even the interpretive structures that had the advantage of modularity, despite the configuration of the controller in the route, this advantage has great challenges.
The independence of the modules is also lost, because in this type of architecture everything starts from the core and the modules have to coordinate themselves with the core.
Limited flexibility
Configuring route in controller configuration can limit application flexibility because controller logic is tightly coupled to route configuration. Configuring the controller in route creates a hard connection. When specifying the controllers in the route, it becomes difficult to change the path without affecting the controller. This makes the code inflexible and hard to maintain. Configuring the controller in the route makes the controller dependent on the routing framework and makes it harder to switch to a different routing framework in the future.
As your application grows, configuring controllers on routes can become cumbersome and difficult to manage. This approach may not scale well for larger and more complex applications. This is because the controller is responsible for handling multiple paths, which can lead to performance issues. Because of specifying the controllers in the route, encapsulation becomes difficult if the controllers are updated and changed.
Difficult project management
One of the disadvantages of this structure is that if we want to manage a diverse number of requests in the second part, it will be necessary to create many methods in the controller class; this makes the controller class difficult to manage.
Note: The meaning of second part is section2 and it is specified in the example below.
Example:example.com/section1/section2/section3/sectionN
Encapsulation becomes very difficult. In fact, it becomes very difficult to separate the parts of the project. When a controller is responsible for managing multiple paths, it can become very complex and difficult to manage. This can lead to code bloat and make it harder to maintain.
When controllers are configured directly into routes, unit testing the controllers in isolation can be more challenging. When an error occurs in a path, it can be challenging to properly handle the error. This is because the controller is tightly coupled to the route and error handling is not easily centralized. Separating the controller configuration from the routing logic can make it easier to write and run tests.
When controllers are configured in routes, it can lead to code organization problems. The code is messy and difficult to understand. If the same controller configuration is required for multiple paths, configuring the controller in each path can lead to code duplication. This can make it more difficult to maintain and update the app in the future. configuration controller in route may result in duplicate code or logic that cannot be easily reused in other parts of the application. In fact, controllers configured in routes are not easily reusable. They are designed to work with a specific route and are not easily compatible with other routes.
MVC in the CodeBehind framework
The Elanat team's CodeBehind framework is an engineering masterpiece that provides a simple and understandable MVC structure.
In the CodeBehind framework, you can support multiple views in one controller.
Views can use the methods and attributes of the controller class.
CodeBehind framework MVC example
View File: Default.aspx (razor syntax)
@page
@controller YourProjectName.DefaultController
@model YourProjectName.DefaultModel
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>@model.PageTitle</title>
</head>
<body>
@model.BodyValue
</body>
</html>
View File: Default.aspx (standard syntax)
<%@ Page Controller="YourProjectName.DefaultController" Model="YourProjectName.DefaultModel" %>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title><%=model.PageTitle%></title>
</head>
<body>
<%=model.BodyValue%>
</body>
</html>
Model File: Default.aspx.Model.cs
using CodeBehind;
namespace YourProjectName
{
public partial class DefaultModel : CodeBehindModel
{
public string PageTitle { get; set; }
public string BodyValue { get; set; }
}
}
Controler File: Default.aspx.Controller.cs
using CodeBehind;
namespace YourProjectName
{
public partial class DefaultController : CodeBehindController
{
public DefaultModel model = new DefaultModel();
public void PageLoad(HttpContext context)
{
model.PageTitle = "My Title";
model.BodyValue = "HTML Body";
View(model);
}
}
}
The example above showed the default structure of the CodeBehind framework without configuring the controller in root.
At the end of this article, it is necessary to mention that it is possible to configure root in the CodeBehind framework and developers can use the root configuration in the CodeBehind framework to create various systems.
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
Top comments (0)