Since the release of Visual Studio 2008, the main desktop platform framework was WPF. Although it is possible to use WPF in an event-driven architecture such as the RAD architecture used in Windows Forms, this is not an efficient solution when fitted across a WPF project. A similar approach will waste long-term programmer productivity, without producing any concrete benefit against performance indicators.

A desktop application requires in low latency, low resource usage, good efficiency, and discrete throughput, while indicators such as scalability and availability are definitely secondary concerns.

For an internal line-of-business (LoB) data-driven application, the best desktop application relies on a layered MVVM application on the WPF framework, released on a 2-tier system architecture. Because of the great low-latency given by WPF, together with asynchronous programming, maintenance costs of MVVM architecture, together with a direct connection to any corporate DBMS, are low, any other external system nullifies the need for middleware or a middle tier with its own maintenance costs. Obviously, for a corporate application that needs to be accessed by thousands of employees, a 3-tier or SOA architecture will be mandatory in order to fulfill scalability needs, reuse logic, and achieve an improved application decoupling from the underlying database.

The ability to use any multithreading technique in such client applications will also give the right throughput to fulfill any elaboration need.

A line-of-business application with multiple DBMS persistence storages

Such architecture will also benefit from the automatic release systems that are offered by Visual Studio with built-in versions and update management, such as ClickOnce. Alternatively, a XBAP browser-enabled WPF application may be developed, but this WPF template is slowly being abandoned by Microsoft and by most of the control/component makers on the market.

The alternative is an SOA-powered architecture that totally differs from a data-driven architecture, such as the one explained earlier. SOA does its best when a complex business logic is the primary concern of the whole design.

Find more information about ClickOnce at http://en.wikipedia.org/wiki/ClickOnce.

Mobile applications are similar to desktop applications in terms of performance needs. While the desktop world today is totally confined to enterprise applications, mobile devices, such as smartphones and tablets, need something similar to the desktop application. However, they're different because essentially they're usually consumer-oriented applications.

Mobile applications need very low resource usage, high efficiency, and a good throughput, if applicable. Indicators such as latency and availability are secondary concerns while scalability is unnecessary as any other single-user application relying on external services for data persistence and complex business logics.

Another factor that's important when developing mobile applications, although not regarding performance, is the need for a reactive UX. A mobile user should never find his device frozen; the UI must always do something to acknowledge that the logic is still being executed. Although the same behavior is suggested also for any desktop class applications, mobile applications specifically need such behavior as a primary concern. This need does not deal with latency; it is more like a partial update to the UI, which is made to improve the user experience. Regarding the system architecture, the target solution for a mobile is a 3-tier architecture with the first tier made by a huge number of devices. Usually, because of the high fluctuation of connected devices, a cloud-based release is suggested.

A widely used mobile device web-service based architecture is described in the following diagram. Reusability of services is available for future versions of mobile applications:

A 3-tier system serving a mobile application

In Visual Studio 2013, new project templates are available and can be used to create multiplatform applications. The Universal Apps project helps to create applications that can work on Windows Phone or Windows with a single shared core logic.

Regarding the architecture, creating a mobile application targeted for a single or multiple platforms does not change the architecture needs. Usually, a cloud service provider is used for single mobile applications because Universal Apps may be targeted for a bigger market, made by a more heterogeneous client style.

Regarding performance, the biggest limitation is the one offered by using a portable library logic internally in mobile code where a small .NET framework (with less features) is available. On the other hand, you can execute complex code outside mobile devices in a web service where there is a full .NET framework stack available. It offers better features with more performance optimization techniques, along with virtually infinite computational power.

The usage of a shared logic in a portable library, or using a Universal Apps project that does the same for us, is priceless for the simplicity of creating a single cross-platform application. The drawback is that we have to know the limitations behind such a choice. It is obvious that a shared library can execute only easy tasks with the small .NET framework available. When things become difficult, is time to move the needed computation outside the device.

What is the alternative? Creating a 3-tier architecture catching all the complex logic (see the previous example about the Web) in the middle tier and multiple presentations for devices and other media. Such a presentation may also use Universal Apps as development projects. With this choice, we can process complex logic and huge datasets in a serviced tier without losing the ability to produce a fashioned mobile application for multiple platforms with as few efforts possible.

A theoretically perfect definition of a web application is that it serves thousands of requests per second, without letting any users feel the traffic on the server. The technical name for this handling is load sensitivity, a specific performance indicator that stands for how much a system changes its other performance indicators with respect to load change. This indicator is definitely part of our simplified meaning of scalability, because if a system is able to handle millions of requests per second with a huge performance drop in all other indicators, this is definitely not good scalability.

Thus, the target performance requisite for a web application is low latency or asynchronous elaboration of jobs in a state-machine workflow manner. High throughput is necessary, and the same goes for scalability, although this means sacrificing indicators such as resource usage and efficiency. Availability is a critical requisite because although we never desire an easy-to-crash system, when dealing with thousands of requests per second, it is obvious that some of those will fail—such failures should never reduce the robustness of the whole system. Availability means that the web application should maintain its healthy status, although some user requests could fail.

Regarding performance, the most balanced architecture is the 2-tier made on ASP.NET MVC. This layered architecture gives a good response time and good scalability and throughput, along with good long-term maintenance level.

A 2-tier system serving a layered MVC web application

An alternative is to use the SOA to create multiple functional isles with multiple web services and persistence storages. This could support heavy loads, extremely high scalability rate, and very complex logic. Obviously, without any of these specific needs, its drawbacks will waste any benefit with the cost of a high development effort.

What differs from a classic, although not legacy, web application and a cloud one is mainly the different technology stacks that sometimes bring different architectural solutions.

Another great difference between these two worlds is the release management. Something actually difficult when working with a 3-tier architecture is handling the service versioning that is needed to fulfill future requirements, along with supporting real time web application subscribed contracts. A typical solution to release the whole software made of all three tiers in a big-bang way, by releasing all tiers together. Although this may seem like a good solution, it is usually difficult to have a new working release of everything, especially when multiple additions are made to the initially designed system architecture.

Here is where a cloud provider such as Microsoft Azure helps us, because all of our application tiers are always in the Cloud Service deployment package. We can say that an Azure Cloud Service always does big-bang releases.

The goal of a 3-tier (and higher) architecture is to externalize core business logic by the presentation layer, which can be updated in time, or reused by serving different frameworks, such as the MVC for web, the MVVM for devices, and so on. With a 3-tier architecture and for SOA too, we have the ability to update only a portion of our application per instance. Obviously, only updates that do not affect other tiers can be made. This gives a great advantage and enables ease of release management and saving time.

Another simplification in release management, scalability, and availability, is the usage of multiple persistence storages, eventually relying on different technologies. A Microsoft Azure 3-tier architecture with multiple persistence storage and asynchronous processing that is made with cloud level queues design is described in the following diagram:

A Microsoft Azure 3-tier architecture

What actually differs from the solution previously seen is the usage of different persistence storages trying to address a winning solution regarding performance, such as relational databases or no-SQL repositories, such as a BLOB storage for files.

Another interesting difference here is the usage of asynchronous task registration. An example is the account registration or any high computational or state machine logic-driven task. With this choice, task data is temporarily stored on a First In First Out (FIFO) container, a message queue with transactional support and automatic re-attempt logic that guarantees the message processing. This asynchronous design is highly scalable and available because in critical load condition, a message will never be lost or unprocessed; in the worst-case scenario, it might be processed with a bit of delay.