When choosing a technology stack for a new project lots of criteria should be taken into consideration (scalability, complexity, cost, etc). If a project is of light or medium complexity — the variety of possible technologies and frameworks may be huge and the choice is usually a matter of preference and experience. However, finding the best stack for a compound system consisting of several different applications — might be a challenge.

For development purposes it would be ideal to use the same technology and programming language across all system parts. It is also essential to consider further development and maintenance after the first release, to think through how developers will “live” along the chosen technologies, resolve the issues and improve the project, how easily it will be to reach version 2.0, 3.0 and so on, and whether it will be possible to adapt the solution to some specific customer requirements.

Our company developed a complex emergency system which comprises processing services, a desktop client and mobile applications for all major platforms. Certainly, the system of this kind has to be reliable and able to process high number of requests. Apart from that, it should surely store and manipulate lots of data, and provide the possibility to scale the services to reach necessary performance, and host them in the public and/or private cloud. Moreover, each service, depending on its tasks, should be started upon request or work 24/7 and respond with a minimal latency. Thus, required services should be hosted differently: some — on the web server, some — as independent applications.

So, we had complex requirements for very different subprojects and we prefered using one platform that would gracefully cover everything and still give us flexibility to make changes when needed. Looking at technology trends, we’ve decided to settle on Microsoft .NET platform. Why? To answer this question let’s take a closer look at main parts of the solution architecture.

In our emergency system the information about an incident comes from dispatchers and the staff that use smartphones and special mobile devices. Dispatchers use the desktop client application, which displays the information about each active incident, builds charts, generates statistics and reports, provides access to all the data in the system. Dispatchers register new incidents through the rich user-friendly UI, see the current location of people on map and how far they are from the incident location. Microsoft .NET provides two main technologies for the desktop applications: WinForms and Windows Presentation Foundation (WPF). The later is actually used by Microsoft itself in the majority of their products. Both of them are well-documented and well-tested frameworks, and are ideal for building rich and responsive UI applications. Moreover, there are a lot of framework and controls, based on WPF and WinForms. For our application we’ve used WPF and DevExpress controls which are extremely convenient when building complex client-side applications.

Other staff use smartphones with our mobile client application for sending alerts, updating statuses and communicating with organization management. The Xamarin technology, actively supported by Microsoft, allowed our team to use the .NET Framework for developing one application for Windows Phone, iOS and Android operating systems at the same time.

Our server side consists of Gateway, several processing and notification services. We host them in a private cloud. Actually, speaking about hosting of .NET services, it’s worth mentioning that there are many options available: at any moment we can migrate, for example, to such well-known clouds as Microsoft Azure and Amazon Web Services, if the product would need such step.

After receiving a raw incident message Gateway service parses it and creates data structure ready for processing. The information about active incidents in our case is stored in the document database, because it’s much easier to store temporary unstructured data in the non-relational schemaless database. On the contrary, all the data that is rarely changed and archive data about incidents are stored in the relational database. And of course, there are a lot of drivers and object-relational mapping (ORM) frameworks for the .NET to work with almost all widely used databases: both, relational and document ones. In our solution we use MongoDB with their official .NET driver that nicely support language-integrated queries (LINQ) exclusively available only in .NET. And for SQL Server — NHibernate ORM.

Initially, most of the services were implemented as RESTful: first, we were using the ServiceStack.NET, then we switched to the Web API. However, performance of HTTPS requests was too slow for us. Hopefully, there are options how to deal with the problem. In one or two weeks we have easily migrated all essential services to the Windows Communication Foundation (WCF) and now they communicate using the TCP protocol. The rest Web API services support Open Web Interface (OWIN) for .NET that means that it’s possible to host each one wherever we need (on IIS, Nginx, self-hosted, etc.) depends on what tasks the service does.

As a result, we have a working complex solution. It is easy to implement new features and improve the existing ones, because the .NET environment provides everything we need. There are a lot of libraries, frameworks, tools, IDEs, documentation available for the .NET. Thus, we are happy with our choice!

Summing up, .NET is a mature well-designed and well-documented platform with a great support of community. Most of the technologies are open-source and free to use in commercial products. Currently, technologies from the .NET stack can be used not only on Windows infrastructure, but also on Linux, Mac, iOS, Android, and even on the embedded devices (using the .NET Micro Framework). In other words, .NET becomes a great solution for almost all kinds of projects you can imagine!

This article was initially published in CIOReview.