Story of Modularity: Achieving Modularity in Web Application
In my Heliosky.Story project, I am planning to create modularity on every part of the system. To achieve modularity, my program has to be able to load module or application part dynamically. Achieving modularity in web programming is not an easy task. Basically I am amazed with WordPress style of modularity, where they provide a full set of modular API so you can easily develop your custom theme, page, or plug-in in a logical manner. As we know, WordPress is built on top of PHP, a scripting language. Every module or application part in WordPress is a PHP script.
Simplicity of Modularity Lies inside PHP
When a user request a WordPress page, WordPress script starts by calling every single PHP script one by one, starts from wp-load.php then wp-settings.php, then through all the activated plugin scripts, and finally the designated theme to render the pages to screen. Each call to the script adds more instruction before the PHP engine interprets and execute the script. Once again notes that PHP is a scripting language, which means that every scripts from wp-load.php until the footer.php on your active theme is loaded into memory and interpreted.
In my (amateur) opinion, while the flexibility of PHP scripting to achieve modularity, which is beautifully implemented in WordPress, this is actually also a drawback for it. Because the more plugin you activate, the more code to be loaded and interpreted. Not all the line of codes loaded in memory is executed, because many of them is just a function definition. If that function is not called by the executing script, those codes just sit there pointlessly. This repeats on each and every request comes to the web server, which actually cost you a lot of execution cost.
The Way ASP.NET Works (At a Glance)
It will be a very different story with ASP.NET application. ASP.NET relies on .NET Framework infrastructure, which every code is compiled into Intermediate Language before it is executed. The IIS Web Server worker, called Application Pool, loads the library once and reuse it on every request to the web server. IIS will only recompile the library if there is change in the source code. In addition, ASP.NET does not only relies on compiled library, but also an ASPX file which defines the page design (in this context we are talking about Web Form application. MVC framework have slightly different mechanism, but actually the concept is the same). ASPX file is interpreted by IIS worker on every request. ASPX is basically an XML file that is a superset of HTML file with the ability to include ASP.NET server objects inside the file.
Some plus side of ASP.NET concept is that it can save the execution by not compiling or interpreting every source code on every page request. ASP.NET worker can only interpret the requested ASPX page and execute the compiled script that is defined for the requested ASPX page. If there is any mismatch between the ASPX and compiled script, the ASP.NET worker raises the exception marking that there is an error in the ASPX file or the compiled script.
But the bad side is, it is not as easy as PHP to add more module to the system. In PHP as I told you previously, you can only include more PHP script to add more functionality to your application. Any script from any people basically can be loaded easily, and by following the defined contract or interface (the way the main application call the custom module), the main application can easily call the custom module as it is loaded in PHP memory. In ASP.NET, you have to do a little bit more than that.
Achieving Modularity in ASP.NET
In general, .NET Application behaves like any other compiled applications: they only know what is compiled inside their own compiled and linked library (set of compiled codes). Developing plugin for an application must be happened beyond the compilation of the main application (which is why it is called plugin). So there is no way for the compiler of main application to link the main application to its plugin. In the other words, the application must have an ability to locate the plugin library dynamically without the help of the compiler.
One way to achieve modularity in this environment is using Reflection. Reflection is a framework provided for the application so the application can load, call, and execute (any) library dynamically during runtime. It can load any code (in Intermediate Language) from any source and execute it like normal program. And as long as the plugin following the defined contract or interface, the application can utilize and execute the plugin seamlessly. It is not as straightforward like PHP, but it is still achievable in ASP.NET environment.
Another way that (I think that it might) work to achieve modularity in ASP.NET environment is to make the application can identify or enumerate ASPX file dynamically. So let say that I have a folder called “Module”. In that folder, I can put as many ASPX files as I want. The ASP.NET application can enumerate all the ASPX inside that folder and put down as a list of available module that can be accessed by user. So if I add another page in that folder, I don’t have to update the main program to locate that module (for example: add more link in master page to access that module).
Remarks
Surely I am still going to experiment with those options available to achieve modularity in ASP.NET application. I will tell you more about my idea on this subject more in the future. Currently I am trying to incorporate custom XML file that act as a module definition for my application, which my application loads the module based on the XML file. Talk to you later 🙂
