Application Architecture
The web application of the platform is structured in four layers:
- Front-end presentation layer based on ASPx pages, complemented by Knockout, JQuery, Typescript and Less libraries.
- Application Programming Interface (API) handling all calls from the presentation layer, or external applications. This layer wraps all the data processing that is handled by the Domain layer.
- Domain layer which performs all data processing and object relation mapping before interacting with the database.
- Database with stored procedures. The stored procedures handle much of the more complex business logic.
Design History
Here are a few clarifications to help understand key design decisions in the application architecture. The application front-end was developed prior to the release of the Microsoft Model View Controller framework. The LINQ to SQL framework, which predates Entity Framework, was used for Object-relational mapping. The business logic has in many cases been implemented in stored procedures in the database layer due to performance considerations. A current development is that the LINQ to SQL framework is gradually being bypassed by firing SQL queries to the database directly.
Web pages layer
The web pages layer consists basically of a collection of ASPx pages that make use of several JavaScript libraries to interact with the Application Programming Interface layer. Some elements that are in common use by multiple pages are referred to as ‘snippets’. The layout of the pages of the pages is governed by cascading style sheets (CSS) and Less for CSS pre-processing.
A recent development is the incorporation of the ASP.NET Signal R framework in both front- and backend for the development of functions that need ‘real time’ and bi-directional communication between server and client. This way the server can push content to connected clients instantly as it becomes available. At time of writing this is implemented for tracking the status of email workflow between location managers and prospect customers.
Multilinguality
The presentation layer makes use of resource files (.resx) to generate the correct presentation for any language. Each language has it’s own set of these files for each entity in the application domain layer. This results in well over 100 files per language. The .resx files are generated by the Microsoft Multilingual Toolkit that takes in .xlf files that are common standard for professional translators. Adding an additional language requires a translation of over a 100 files.
To date, five languages are supported in the front-end application: English, Dutch, German, Spanish and Portuguese. The backend functionality is provided in English only.
Domain and database layers
This layer contains all code that maps all API request to calls to the database, its views and stored procedures. More background information on the LINQ to SQL framework that is used can be found here: https://msdn.microsoft.com/en-us/library/bb386976(v=vs.110).aspx
The ASP.NET Signal R framework (mentioned in 4.2.2) is also applied in the domain layer to facilitate content push from server to clients.
For an impression of the table layout in the database, please refer to Appendix 1. Here a schema generated from Visual Studio is provided for some data intensive classes.
Presentation
This layer consists of many files in many folders. Mapping the page flows to each of the pages and their components and styling convention, requires hands-on experience with the page structure, the used libraries, configuration and translation files. An experienced .net developer should be able to find his/her way fairly easy.
Application Programming Interface
The API has a clear structure that requires a conceptual understanding of the application services that are available on the system. Some of the required higher-level clarification is provided by this document as well as more in depth in the separately available API manual and the additional online reference (https://staging.seats2meet.com/help).
Domain and Database
Within the scope of this version of this document, there has not been an extensive survey of the domain and database layers and their interaction. Processes such as the calculation of pricing information, as part of the yield management logic of the application, involve stored procedures with nested SQL statements. These procedures may prove to be the most intricate part of the application. For an impression of the data structures in the database, please refer to Appendix 1.
Third party integration
In addition to the API that is provided by the system, webhooks can be used to push information to third party APIs. To date, integrations have been made with a partner’s SAP system and CRM system to provide them with booking information.
