All articles

Prism Methodology

In the case where applications are developed for XAML-based platforms, such as WPF, Silverlight, Windows Phone, or Windows Store, the Prism methodology will certainly help to simplify their development.

Prism is a tutorial that is designed to help develop and build rich, flexible and easily supported Windows Presentation Foundation (WPF) applications, Silverlight Rich Internet Applications (RIAs), and programs for Windows Phone 7-8, as well as Windows Store applications . Using design patterns that embody important principles of architectural design, such as Separation of Concerns (SoC) and Loose coupling, Prism helps design and develop applications with loosely coupled components that can be independently developed and then combined into one the whole with minimal effort. This type of application is known as composite applications.

Prism is for developers of WPF, or Silverlight applications with multiple screens, enhanced user interaction, data visualization, and complex interaction of views and business logic. These applications usually interact with multiple back-end systems and services and, using a multi-level architecture, can be physically deployed on several levels. It is expected that the application will significantly evolve during his life, in response to new business requirements. In short, these applications are built for a long time and for changes. Applications that do not require these features may not benefit from using Prism.

Why Use the Prism Methodology

Designing and developing rich WPF or Silverlight applications that are flexible and supported can be a challenge. This section describes some common problems that can arise when creating them and how Prism helps in their solution.

Problems in developing client applications

As a rule, developers of client applications encounter many problems. The requirements for the application may change over time. New business opportunities and problems may appear, new technologies may become available, or even customer feedback during the development cycle can significantly affect the application requirements. Therefore, it is important to write applications so that they are flexible and can be easily changed or expanded in the future. Creating such a level of flexibility can be difficult to achieve. This may require an architecture that will allow individual parts of the application to be developed and tested independently and that can be modified or updated later in isolation without affecting the rest of the application.

Most corporate applications are complex and require a whole team of programmers and designers to develop. How to develop applications in such a way that several developers or teams can effectively work on different parts of the application independently and be sure that parts of the application are seamlessly connected during integration can be a serious problem.

Design and development in a monolithic style can lead to an application that is very difficult and inefficient to maintain. In this case, the word “monolithic” refers to an application in which the components are very closely related and there is no clear separation between them. Typically, applications designed and built in this way suffer from problems that make the developer’s life difficult and full of suffering. It is difficult to add new functions to the system, or to replace existing functions, it is difficult to correct errors without affecting other parts of the system. This application is difficult to test and deploy. In addition, all this affects the effectiveness of interaction between developers and designers.

A composite approach

An effective way to solve these problems is to divide the application into a number of discrete, loosely coupled, semi-independent parts, which can then be easily integrated into the shell application to form an integral solution. Applications designed and built in this way are often called composite applications.

Compound applications have many advantages, including the following:

  • Allow modules to be developed, tested, and deployed to different individuals or subcommands. These modules can also be easily changed, or supplemented with new functionality, which allows the application to be supported and extensively maintained. Note that using this approach, the project of even one person can benefit from the creation of a well-tested and supported application.
  • They have a common shell that contains user interface components that are provided by various modules that are loosely coupled to each other. This reduces the discord that occurs when multiple developers add new functionality to the user interface and provide a seamless appearance.
  • Facilitate the reuse of code and the sharing of responsibilities between horizontal levels of the application, such as authorization and authentication and vertical levels, such as business functions specific to your application. It also allows you to easily manage dependencies and interactions between application components.
  • Help to support the separation of roles, allowing different individuals or teams to focus on a specific task, or a piece of functionality, according to their specialization or experience. In particular, this provides a cleaner separation between the user interface and the application’s business logic. This means that the designer can focus on creating a more user-friendly interface, and the programmer – on creating more complex business logic.

Compound applications are ideal for a number of client scenarios. For example, a composite application is ideal for creating a rich client application over heterogeneous back-end systems. The following figure shows an example of this type of application.

In this type of application, the user can be presented with a rich and flexible user interface, focused on functionality. These applications can consist of several server systems, services and data stores, each of which is represented by one or more dedicated modules. A clear separation between the application logic and the user interface makes it possible to provide a consistent and separate view of all the composite modules.

In addition, a composite application can be useful when there are self-developing components of the user interface that are poorly integrated with each other and supported by separate commands. The following figure shows an example screen for this type of application. Each of the selected areas represents independent components, united in the user interface.

In this case, the composite application allows the user interface to be composed dynamically, at runtime. This provides flexible options for the user. For example, this allows new functions to be dynamically added at run time, which provides rich customization capabilities and easy extensibility.

Problems that are not solved by using Prism

Although Prism will help you solve many of the problems that you may encounter when creating WPF or Silverlight applications, there are many other problems that you may encounter depending on the scenarios and requirements. For example, Prism does not directly address the following topics:

  • Unstable connection and data synchronization.
  • Creation of distributed and cloud applications.
  • Authentication and authorization.
  • Application performance.
  • Version control of the application.
  • Error handling and fault tolerance.