Note: In every part of the text of the article where ASP.NET Core is mentioned, we mean programming with default cshtml pages in ASP.NET Core.
Note: We mean by web part in this article, it can also mean add-on, plugin, module, and Extensions, etc.; if you read to the end of the article, you will understand what we mean by web part.
CodeBehind story
First, CodeBehind was supposed to be a back-end framework for the C++ programming language; our project in C++ was going well, we built the listener structure and we were even able to implement fast-cgi in the coding phase for the Windows operating system. Windows operating system test with nginx web server was very stable and fast; but for some reason, we stopped working and implemented CodeBehind on .NET Core version 7 (maybe we will explain about this in an article in the future).
CodeBehind library is a back-end framework. This library is a programming model based on the MVC pattern, which provides the possibility of creating dynamic aspx files (similar to ASP.NET standard) in ASP.NET Core and has high serverside independence. CodeBehind is free and open-source.
Programming in CodeBehind is simple. The simplicity of the CodeBehind project is the result of two years of study and research on back-end frameworks and how they support web parts.
Simple and structured MVC in CodeBehind
View File: Default.aspx
<%@ 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: DefaultModel.cs
using CodeBehind;
namespace YourProjectName
{
public partial class DefaultModel : CodeBehindModel
{
public string PageTitle { get; set; }
public string BodyValue { get; set; }
}
}
Controler File: DefaultController.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);
}
}
}
As you can see, there is an extraordinary structure in the controller section, which consists of a function named PageLoad and is called with every request of this function
To receive the information sent through the form, you can follow the instructions below:
public DefaultModel model = new DefaultModel();
public void PageLoad(HttpContext context)
{
if (!string.IsNullOrEmpty(context.Request.Form["btn_Add"]))
btn_Add_Click(context);
View(model);
}
private void btn_Add_Click(HttpContext context)
{
model.PageTitle = "btn_Add Button Clicked";
model.FileUploadValue = context.Request.Form.Files["upd_FileUpload"];
model.AcceptChechedValue = context.Request.Form["cbx_AcceptCheched"] == "on";
model.GuestNameValue = context.Request.Form["txt_GuestName"];
}
Sending data through the form is shown for you in the codes above; You can see the simplicity and comprehensibility of the code.
By using CodeBehind you can call the output of any page on any other page (or anywhere).
aspx page
<%@ Page Controller="YourProjectName.DefaultController" Model="YourProjectName.DefaultModel" %><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title><%=model.PageTitle%></title>
</head>
<body>
<%=model.LeftMenuValue%>
<div class="main_content">
<%=model.MainContentValue%>
</div>
<%=model.RightMenuValue%>
</body>
</html>
Controller class
using CodeBehind;
namespace YourProjectName
{
public partial class DefaultController : CodeBehindController
{
public DefaultModel model = new DefaultModel();
public void PageLoad(HttpContext context)
{
model.PageTitle = "My Title";
CodeBehindExecute execute = new CodeBehindExecute();
// Add Left Menu Page
model.LeftMenuValue = execute.Run(context, "/menu/left.aspx");
// Add Right Menu Page
model.RightMenuValue = execute.Run(context, "/menu/right.aspx");
// Add Main Content Page
model.MainContentValue = execute.Run(context, "/pages/main.aspx");
View(model);
}
}
}
Each of the pages left.aspx, right.aspx and main.aspx can also call several other aspx files; these calls can definitely be dynamic and an add-on can be executed that the kernel programmers don't even know about.
You can even call pages with query strings.
model.MainContentValue = execute.Run(context, "/pages/main.aspx?template=1");
You can also call a path that is determined at runtime and may change over time.
string MainPage = Pages.GetDefaultPage();
model.MainContentValue = execute.Run(context, MainPage);
Many developers avoid ASP.NET Core and choose interpretive frameworks like Django and Laravel. And this is due to the complexities and weak default structure of ASP.NET Core and the need for complex configurations and controller classes with a chaotic and incomprehensible structure for novice programmers, as well as the difficulty of building a modular system.
Really, no matter what we tried, we couldn't find any advantages to using ASP.NET Core compared to CodeBehind; perhaps if we were to compare ASP.NET Core with frameworks such as Django and Laravel, we could introduce high execution speed and leading programming language C# as a measure of ASP.NET Core's superiority; but using CodeBehind will give us the same advantages. If you have one or more better advantages for ASP.NET Core than CodeBehind, be sure to share your thoughts with us.
CodeBehind in version 1.5
CodeBehind is currently in stable state at version 1.5. And in the future, newer versions will be released and more features will be added to it.
CodeBehind advantages
CodeBehind is a flexible framework. CodeBehind inherits all the advantages of ASP.NET Core and gives it more simplicity, power and flexibility.
One of the great features that Code-Behind gives you is the support for DLL libraries. You can add all the .NET Core DLL libraries that you have created into the bin directory located in wwwroot so that the Code-Behind will call all of them.
How to add web part? First, copy your compiled project files to the desired path in wwwroot; then copy the main dll file to wwwroot/bin path. You can do the copy while the process is running in the method and then call the code below to compile without restarting the program.
// Recompile
CodeBehindCompiler.Initialization();
CodeBehindCompiler.CompileAspx();
CodeBehind, like the default ASP.NET Core, supports multiple platforms, and in the test conducted by the Elanat team, it also has high stability on Linux.
CodeBehind occupies less memory resources (ram) than ASP.NET Core.
Aspx pages are compiled in CodeBehind and their calling is done at a very high speed, so that the path of the aspx file is not even referred to during the calling.
In CodeBehind, the physical executable pages (aspx) are placed in the root path, and this makes the program structured.
CodeBehind supports web parts; web parts are like other parts of the project and include aspx files.
To add the web part in CodeBehind, just put the project files in the root.
In CodeBehind, you can run web parts that make changes to aspx files. You can edit all aspx files during project execution and responding to users.
In CodeBehind, the structure of web parts is the same as the structure of the main project; Your main project includes aspx pages, dll files, and other client-side files (css, js, images, etc.); web parts in CodeBehind also include aspx pages, dll files and other client side files.
The project created by using CodeBehind is automatically a modular project, that is, it has the ability to add web parts. In addition, each web part can be used in other projects.
The system built with CodeBehind is also a web part itself. Each web part can also be a separate system! The web part that adds the configuration of the Program.cs class is considered the main system.
CodeBehind stores the final values of its pages outside of the Response in the HttpContext; you can edit the output of the final values in the aspx pages before the answer. This gives you more control than ASP.NET Core.
CodeBehind produces understandable code, while the Controller part of ASP.NET Core is a messy and complex situation.
You will never experience the power that the CodeBehind framework gives you in ASP.NET Core.
.NET developers accept CodeBehind as part of the larger .NET ecosystem. Whatever benefits CodeBehind has belongs to the .NET community.
CodeBehind is similar to interpreted frameworks such as Django and Laravel, and programmers of interpreted programming language projects can easily program with CodeBehind.
Developers of interpretative frameworks can consider CodeBehind as an alternative.
Elanat is based on CodeBehind
Elanat is a add-on-oriented system and its implementation was first done with ASP.NET Standard and then migrated to ASP.NET Core after only 2 weeks by using CodeBehind. Elanat content management system is the most powerful .NET system.
Elanat is built using CodeBehind and provides the following features:
Adding an add-on to Elanat is done without stopping or restarting the program and without deleting sessions.
Existence of scheduled task
https://github.com/elanatframework/Elanat/blob/elanat_framework/wwwroot/App_Data/scheduled_tasks_list/scheduled_tasks.xml
The existence of a startup
https://github.com/elanatframework/Elanat/blob/elanat_framework/wwwroot/App_Data/start_up_list/start_up.xml
Existence of reference lists
Before load path reference
https://github.com/elanatframework/Elanat/blob/elanat_framework/wwwroot/App_Data/before_load_path_reference_list/before_load_path_reference.xml
After load path reference
https://github.com/elanatframework/Elanat/blob/elanat_framework/wwwroot/App_Data/after_load_path_reference_list/after_load_path_reference.xml
Event reference
https://github.com/elanatframework/Elanat/blob/elanat_framework/wwwroot/App_Data/event_reference_list/event_reference.xml
The program that is created under CodeBehind is highly extensible and creating these features is very simple. Implementing these things in ASP.NET Core becomes very challenging; it will be more difficult to implement even than ASP.NET Standard.
Note: These features were also available in the standard .NET version of Elanat, and we put a lot of effort into creating them and generated high-level code to bypass the limitations of the .NET standard. At the same time, adding the add-on to the Elanat .NET standard version required stopping the program; Also, in .NET standard version, we could not control all the unwanted paths.
We said this so that you understand that the implementation of such structures may be possible in ASP.NET Core, but it will require large configurations and solving many challenges. Maybe you need to spend 6 months in your big team to be able to implement such structures in ASP.NET Core, but still you will not get the desired result and you will not have the power of CodeBehind; it is interesting to know that the implementation of the previous version of Elanat using ASP.NET Standard took 10 years! (Maybe in the future we will explain in detail about the big challenges we went through to make Elanat have an add-on-oriented structure in an article).
It is recommended to research the following about ASP.NET Core and then compare with CodeBehind:
- Load a cshtml page from another cshtml page
- Changes in cshtml pages after publication and deployment on the web
- Call the path of an executable page specified at runtime on the current page
- About how to add web parts
- Ability to add web parts without restarting the running project
- The possibility of reusing web parts
- Access to the route's output response
- Adding a large project to a very large project
- Challenges of moving the project to new versions
CodeBehind in NuGet:
https://www.nuget.org/packages/CodeBehind
CodeBehind repository link:
https://github.com/elanatframework/Code_behind
CodeBehind page in Elanat website:
https://elanat.net/page_content/code_behind
Be sure to use CodeBehind and give us feedback.
Top comments (2)
Very interesting.
My application is written using devexpress web forms. It would be great if this project was aimed at helping to gradually port applications to a modern platform like blazor.
It's a pain
Hello, dear Vladimir
On the client side, everything is fine and HTML, CSS, and JavaScript work very well; but for some graphical or processing cases, JavaScript does not perform well.
In my opinion, webassembly was a big mistake. It would be better to create a standard so that browsers support an intermediate language (such as MSIL or Java bytecode); if this were the case, the JavaScript files would be compiled in advance and would be responsive to graphics or heavy processing at a higher speed; the compiled JavaScript file was saved with jsc extension; there were also no other complications; currently, it is very difficult and complicated to create a webassembly outside the Microsoft ecosystem.