If you’re used to developing for Windows (or MacOS or Linux or really any desktop OS) and you are contemplating a Web version of your application, there are a variety of things to consider. Moving from C# to HTML is more than just learning some different syntax and related frameworks. It's a whole new world.
It may be obvious, but let me state it anyway: the Web is not Windows.
This is the first in a series where we’ll review some fundamental differences and discuss how we address those with WebMAP’s application architecture. That architectural pattern may take a little getting used to, but in the long run I think you’ll find it makes your life simpler when you go to maintain or improve your Web application. Many thanks to our own Chief Rocket Scientist Mauricio Rojas for pulling a lot of this together.
Note: some of this discussion may be a bit basic for some readers, but in order not to leave people behind I’ve chosen to cover some fundamentals before moving into advanced topics. (That’s why there’s a Page Down key on the keyboard.)
In .NET we’re very familiar with something like this:
public class Autos { public string Name { get; set; } } static void Main(string[] args) { Autos jetta = new Autos(); Autos camry = new Autos(); jetta.Name = "Jetta"; }
In Windows your application is a process in the operating system and, when you create an instance with the new operator the OS allocates some memory for that object based on its type. In the sample above, when the line
Autos jetta = new Autos();
Is executed by the application, Windows allocates some memory to instantiate the object, then when the line
jetta.Name = "Jetta";
is executed it actually writes the string “Jetta” to the memory location it created with the new operator.
Methods like get() or set() read or write that memory location. That’s all possible because Windows knows who owns the memory (the process) and as long as the process is alive the memory will be too, until the object is destroyed and the garbage collector frees the allocated memory. That might be when the object goes out of scope or when you terminate the process (ie close the application).
Back in the stone age when we wrote programs in C or C++ we had to do stuff like malloc() and keep track of object memory ourselves but .NET manages all that infrastructure & bookkeeping for us, leaving us free to focus on what the program is actually doing.
Basically none of this is true for a Web application.
Note we’re talking about a Web application, not a Web site. (In a Web site, the Web server receives a bunch of requests for Web pages (discrete chunks of HTML code) via HTTP GET messages, which it returns to the requestor via HTTP. Pretty simple.) In a Web application, on the other hand, you need to replace the familiar Windows UI (Windows forms or WPF) with controls written in JavaScript, HTML, CSS, and which run inside a browser. Instead of a rich runtime (the .NET classes) to handle communication between the UI and the code, you have to rely on sending data over an open network to a distant server. Recall that neither the Web nor HTTP was intended for what we use it for today; in consequence this stuff can get complicated. So moving from C# to HTML can be tricky.
In a windows desktop application the concept of state is so transparent to you as a developer that you hardly need to think about it. Your application knows it only has one instance and one user to deal with; state becomes basically the in-memory footprint of all the objects in scope at any given moment. If you set the value of a string to “foo” you can be comfortable that it will stay that way, available for retrieval through a “get” method or modification through a “set” method.
The lifecycle for an object in Windows is short and sweet:
A Web application is quite a different kettle of fish. Chief among the different fish species is the fact that each Web application user doesn’t own their own process space on the server, rather their code is just a separate execution thread. This rather handily lets you use one server for multiple user sessions, instead of having a single server dedicated to every user session. The downside is you can’t own memory--you have to share it like kids with a playground slide.
The lifecycle of an object on a Web server looks more like this:
Another key difference to keep in mind is that Web servers basically sit and listen for requests. When they get one, the first thing they need to ask is “Do I know you?” If five different app users all press “submit” with a request to fetch data from the SQL database and return it to a control on a form (like a list box), the server has to keep straight:
The server, in turn, has to also be performant, so it needs structure and tools to minimize the delays in processing requests as well as make load balancing and scaling efficient. Given that a typical Web application is accessed over a public network, inherent latency in the network transport layer already puts a performance burden on this application model compared to a desktop app running on a fast PC. Slowing it down further by poor server implementation could make the user experience untenable.
Some key differences between Windows and Web applications:
You can use our analyzer to tell you how ready your C# app is to migrate to HTML. In the next installment, we'll discuss how to create a loosely-coupled architecture for a Web application.