Application facade
The application facade (English Application Facade ) is an analytical model of the Software Engineering by Martin Fowler that the organization of layered architectures improved. The basic principle is similar to that of the GoF's “ Facade ” design template . Both patterns simplify the use of a complex subsystem through access via a special interface.
Layer architecture
The use of the application facade requires a division of the application into several layers (multi-tier architecture):
- Data source layer
- Domain layer
- application
- Application logic
- Presentation layer
Typically the presentation layer can only process simple data types , while the domain contains complex abstract data types . Therefore, the application logic must translate the data coming from the domain layer for the presentation layer, which is kept simple. Conversely, it is responsible for bringing the data entered by the user into the domain in a suitable form. In order to facilitate the programming of user interfaces, the application facade sample can be used at this point.
In environments where the application is distributed across different processes (as in the client-server model ), the facade should also be distributed. Inquiries from the presentation layer to the client-side facade are then passed on to a facade on the server and processed there.
See also : problem domain
principle
The idea behind the application facade is basically quite simple. Just like the facade of a house, it hides the intricate framework that forms the actual substance. In doing so, it creates a logical perspective. Since you can usually have many perspectives on a business model, there is often more than just one application facade. The trick is to bring individual parts from the domain layer together and make them available so that a logical image is created.
Let's imagine the software system of a bank. In the domain layer there is customer master data, accounts, custody accounts, loans and transactions, among other things. The sales department classifies customers according to this data. A “classified customer” facade can be introduced here. It will getClassification()offer a method that appears simple on the outside; however, the algorithm that searches the domain and keeps it consistent may be complex. It searches the objects of the domain depending on the respective customer and returns a string ("A", "B", ...). A simple call of the method is then sufficient to output the classification of a customer on the screen (here as a Java implementation):
ClassifiedCustomer classifiedCus = ClassifiedCustomer.getByName("Max Mustermann");
System.out.println(classifiedCus.getClassification());
implementation
Martin Fowler gives quite specific information about the implementation of the application facade (which is rather astonishing for an analysis sample). Every application facade has a subject , i.e. a specific object from the domain. This object is used as the starting point for all actions to be taken. The visibility of the subject is to be set to private .
In our example above, the subject of the application facade "classified customer" would be a simple object of the type "customer". From there you can ClassifiedCustomernavigate to the individual accounts, securities accounts and transaction data or find and edit the classification in a classification system. The classification is now an attribute of the application facade ClassifiedCustomer. But be careful: all attributes of a facade should be of the types that also appear in the domain layer.
See also: Object-Oriented Programming
Accessors
Martin Fowler calls the accessors of the application facade retrieval method and means what is generally understood by a getter . This method has the task of getting the current value of an attribute from the domain layer and returning it. In some cases this task can be a lot more complicated than it seems at first glance.
Let us assume that a customer of our bank wants to know the current status of his total assets. The balances of all accounts, all loans and all custody accounts must be taken into account and charged. There is also the question of how to ensure that the invoice contains the current values. The application facade hides such difficult processes behind a simple method interface:
classifiedCus.getTotalBalance();
When implementing such methods, it must be ensured that the return type differs from the actual type of the examined attribute. For example, while a complex data type ( quantity ) should be used for the attribute , the graphical user interface will expect a floating point number.
Manipulators
Of course, an application facade must also offer methods for manipulating the attributes, so-called update methods . These setters can also be very complex. Not infrequently they require considerable effort. There are many relationships between the objects of the domain layer, which is precisely why the application facade is used. If one of these objects is changed, dependent objects may also have to be updated.
As an example, let's look for one of our customers who is classified as a "C-customer" (that is, at the lower end of our system) and use the update method to update his account due to an unexpected cash blessing:
classifiedCus.setBalance(new Quantity(1000000,Unit.get("Euro")));
Obviously, it must now be ensured that the customer's rating is updated automatically. Alternatively, the classification could also be marked as not up-to-date and brought up to date with the next query.
But that's not all. There are still many other conceivable scenarios that can complicate the implementation of an update method . For example, it might not be permissible in a system to simply overwrite its old value when setting an attribute. Then the old value has to be saved or marked somehow during an update. Update methods for attributes that are defined as collections also make implementation time-consuming. In this case, two methods are required: one to add values to the list and one to delete.
Validator
If data is brought into the domain layer, i.e. values of objects are changed, it must be ensured that this data is also plausible. In simple cases it may be sufficient to have a list of possible characteristics for qualitative characteristic types and to have limits for quantitative characteristics. This is done in the form of a legal values method . The validation method then simply checks whether the given value is listed in the list of permitted values or whether it is within the specified limits. Sometimes checking for admissibility is not that easy, for example when it comes to dates.
Default values
Finally, the application facade also includes a so-called default method . Behind it is an effective trick to further reduce complexity. If you initially assign standard values to a data record when you create it, you can simply use the update method when entering the initial values. The implementation of the default values method is very simple, it is basically a special getter . The system can thus be simplified with little effort.
| method | OO name | function |
|---|---|---|
| retrieve | get | Accessory |
| update | set | manipulator |
| legal values | List of permissible values / limit values | |
| validation | Validator | |
| default | Set default value |
Multiple application facades
The use of several application facades offers further possibilities to improve the architecture of the application. If a view of the presentation layer uses information from several facades, it can provide the user with completely new representations. Inheritance can also be used sensibly with facades. In our example of banking software, there is probably an application facade “Customer”, so “ClassifiedCustomer” is just a specialization. Such procedures also improve the system in terms of flexibility and stability.
Example implementation
Martin Fowler provides a detailed example of how the application facade works in his article "Application Facades". He explains the idea and implementation using an information system for hospitals. In addition, the program , which is held in Java , includes many other analysis patterns from Fowler, for example:
The detailed example goes into the details of the methodology and shows the use of module tests . Despite the many fragments, some parts are missing for the complete implementation.
With a partial implementation of the example program in Python it could be shown that with Fowler's approach it is even possible to convert it into a program that can be reconfigured at runtime .
literature
- Martin Fowler : Analysis Pattern: Reusable Object Models . Addison-Wesley-Longman, Bonn 1999, ISBN 3-8273-1434-8 .
- Erich Gamma , Richard Helm, Ralph Johnson , John Vlissides : Design Patterns: Elements of Reusable Object-Oriented Software . Addison-Wesley, 1996, ISBN 0-201-63361-2 .
