elanatframework

Posted on Jul 12, 2023

Why should we use Code-Behind?

#csharp #programming #tutorial #coding

A respected .NET developer asked Elanat a question. Our reply to him was longer than can be said in a comment; So we decided to create a new article to help other developers as well.

His question was:

Hi there! I have a small question about this section of your article:

The powerful Code-Behind library allows Elanat to have more freedom in presenting new features compared to the default dot net core MVC structure, which includes cshtml pages, and avoids the unnecessary limitations of Microsoft's aspdotnet core that are used by similar dot net systems.

Can you explain what kind of unnecessary limitations you experience that code behind does not have? I personally have been using MVC approach with razor most of the time and I feel quite the opposite. Not to mention, razor pages seem quite similar in the sense that you have a razor page coupled with a C# file with a similar page load method. They just have somewhat different syntax. I'm curious about how aspx pages with code behind are better in your opinion.

Dear Dennis
Thank you for your opinion

We didn't talk about the Razor syntax and how it compares to the syntax of the <% %> and <%= %> tags that were or are still used in Java JSP or Microsoft asp and aspx web pages. It is even possible to add Razor syntax support to the Code-Behind infrastructure in the future.

In that paragraph (which you quoted) it was blind to the use of the words cshtml pages to emphasize the default structure of .NET.

Existence of executable physical file (aspx) in the root makes your program more structured. Note that after running the program and compiling the aspx pages by Code-Behind, your program will no longer refer to any of the aspx files.

If the scale of the program you are building is high or you need to act dynamically, using Code-Behind will definitely give you more freedom.
If the scale of the program is low, using Code-Behind will simplify your program and you will generate faster and more understandable code.

The following example shows the power of Code-Behind:

aspx page

<%@ Page Controller="YourProjectName.wwwroot.DefaultController" Model="YourProjectName.wwwroot.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.wwwroot
{
    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
            context.Request.Path = "/menu/left.aspx";
            model.LeftMenuValue = execute.Run(context);


            // Add Right Menu Page
            context.Request.Path = "/menu/right.aspx";
            model.RightMenuValue = execute.Run(context);


            // Add Main Content Page
            context.Request.Path = "/pages/main.aspx";
            model.MainContentValue = execute.Run(context);

            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.

Enjoy Code-Behind, but be careful not to loop the program! (Don't call pages that call the current page)

What power does Code-Behind give you while running the program?

Accessing hypertext contents of pages and replacing some values before calling in other pages.

Microsoft usually ties your hands so that you cannot create a dynamic system.

By using the default architecture of Microsoft's ASP.NET Core, you will face some very big challenges. Creating a system with the ability to support plugins that both provides security and does not loop and can call other pages on your pages is very challenging.

We overcame many challenges in standard .NET versions to create a add-on-oriented structure using .NET.

You can refer to the following pages to see a corner of our struggle with the limitations of .NET:
https://github.com/elanatframework/Elanat/blob/elanat_framework/PathHandlersLoader.aspx.cs
https://github.com/elanatframework/Elanat/blob/elanat_framework/PageHandlersLoader.aspx.cs

Suppose you have created an application using the default ASP.NET Core cshtml that has a main page that includes a right menu and a left menu. As we have shown in the code above, can you change the values of these menus to Fill the dynamic form with cshtml pages and replace the values obtained from the pages? It is definitely possible, but it is difficult.
Code-Behind will not even refer to the physical aspx file to call the aspx pages and will only call a method.

How do you manage events in ASP.NET Core?
For example, a route from your program that requires several methods to be executed and these methods do not exist in the core of your program! This work can be blinded with the default cshtml of .NET, but it is difficult.
For example, we should have an event before the request to the search page and not allow the user to do more than 2 searches per minute. Using Code-Behind, we only need to check an aspx page, then reject or allow the search request.

Have you ever tried to create a plugin, module or a dynamic page for .NET systems?
Have you ever built a .NET system that supports a plugin, module, or a dynamic page add-on?
Have you ever wondered why this process is so difficult in .NET!

In the future, we will try to prepare an article on the criticism of the controller structure and the default model of ASP.NET Core.

Top comments (5)

Anthony Fung • Jul 12 '23

If the scale of the program you are building is high or you need to act dynamically, using Code-Behind will definitely give you more freedom.
If the scale of the program is low, using Code-Behind will simplify your program and you will generate faster and more understandable code.

Definitely agree with this, and I've found it to be true when writing MVVM apps too.

There are some things that just can't be done using a view-model only.

However, things are generally tidier when using a view-model with data binding. It's all a compromise based on the app's needs.

elanatframework • Jul 12 '23

Dear Anthony Fung

When we use the word Code-Behind, we mean only the CodeBehind library that was created by ourselves to have more freedom in providing the Elanat framework in .NET Core.

The CodeBehind library is available to everyone for free and open source.

Note that the Code-Behind library is an MVC-based coding structure and is completely different from the old Microsoft Web-Forms structure. We at Elanat team want to expand the CodeBehind library in such a way that there is no need to write server-side codes in view pages, and there is no need to combine any components related to client-side pages with server-side codes. That's why we chose the name CodeBehind for our data presentation library.

Examples of server-side coding in view pages:

<table>
    <thead>
        <tr>
            <th>Column1</th>
            <th>Column2</th>
            <th>Column3</th>
        </tr>
    </thead>
    <tbody>
        @foreach (var item in Model)
        {
            <tr>
                <td>@item.Column1</td>
                <td>@item.Column2</td>
                <td>@item.Column3</td>
            </tr>
        }
    </tbody>
</table>

An example of combining html tags with server-side codes:

model.ListValue = "<ul>";

foreach(string s in List)
    model.ListValue += "<li>" + s + "</li>";

model.ListValue += "</ul>";

There is usually an important need to create for, foreach, and while loops on the view side, and we will provide a suitable solution for that in the future (although we still allow server-side coding in the view!).

The separation of the server-side codes from the view pages makes the web design team separate from the server programming team, and each of them can work without having to talk to the other.

Microsoft used to insist on this issue a lot
learn.microsoft.com/en-us/troubles...

It is interesting to know that we built Elanat in such a way that we did not do server-side coding in the view (aspx) side, nor did we add HTML tags in the server-side codes.
elanat.net/page_content/documentat...

Elanat on GitHub:
github.com/elanatframework/Elanat

Elanat website:
elanat.net

Code-Behind library on GitHub:
github.com/elanatframework/Code_be...

Code-Behind library in Nuget:
nuget.org/packages/CodeBehind

Anthony Fung • Jul 12 '23

Ah... sorry - an honest mistake.

I was using code-behind in the generic sense of WPF/Avalonia programming where it's the code behind the XAML of a view. The concept sounded very similar - just applied to HTML; hence the confusion.

Still - I got to learn about a cool library. Sorry for the mix-up, and thanks for the clarification 👍

John Owolabi Idogun • Jul 13 '23

Welcome to the community ☺️

Dennis • Jul 12 '23

Hi again! Thanks a lot for your elaborate response to my question! Your example clearly demonstrates how easy it becomes to extend, modify or even replace the left and right menus with an add-on. In a standard MVC app with razor, that would take more effort.

Very cool, I learned something new today.

DEV Community

Why should we use Code-Behind?

Top comments (5)

Read next

🚀 21 Tools to take your dev skills to the moon 🌝

Creating Partitions and Mounting File Systems in Linux

Locally test and validate your Renovate configuration files

How to create a dark mode toggle with Tailwind CSS and Alpinejs