Multi-tier desktop applications are typically used in internal enterprise systems that are not exposed over the web. The presentation tier runs on the user's machine and connects to the middle tier to read and update the enterprise data. The middle tier performs any validation and propagation logic to ensure data validity and consistency. It may service multiple clients and possibly provide different types of interfaces for different clients.
The following diagram demonstrates how the multi-tier desktop application architecture is implemented using the default Xomega solution template.
Presentation Tier
Presentation tier, which runs as a windows application on the user’s machine, follows the Model-View-View Model (MVVM) development paradigms where the
Views that represent the visual forms and controls defined in XAML get bound to the corresponding
View Models that store the actual
Model data for the view, the state and meta-data for that model data, such as whether this data is editable or required or the list of values it can accept, and also provide any functions that validate the data on the client side or convert the data from one format to another, e.g. between the UI format and the internal values.
The actual presentation tier logic is encapsulated in the
Code behind that runs when the user opens the corresponding WPF form. It instantiates a new
View Model and then binds it to the current
View using Xomega Framework, which provides two-way binding. This means that whenever the user changes anything on the screen it will be automatically propagated to the model and vice versa – when the application changes the view model, it will be automatically reflected in the view that is bound to it. The code behind reads any data from the middle tier into the View Model, and also handles UI events and updates the middle tier as a result.
The view models are implemented using Xomega Framework data object classes, which significantly simplifies both defining such data objects and its properties by providing all the plumbing for them such as validations, data conversion and formatting, lists of values and so forth, as well as binding view elements to those properties by implementing custom WPF bindings. These Xomega data objects may implement significant part of the UI behavior without any dependency on the WPF application, which means that you can reuse them in other types of clients such as Silverlight or ASP.NET by simply binding them to a different XAML or ASPX view respectively.
Moreover, Xomega Framework data objects for the application are mostly automatically generated from the Xomega service model operations described in this document with ability to extend them in separate classes, so that the data objects could be regenerated any time the service model changes. The standard search and details forms with code behind can also be initially generated from the Xomega service model, which can help boost the development productivity as the developers could start with an 80% or so complete working form and then update it and add the remaining 20% of functionality.
Middle Tier
The middle tier, which runs as a separate service on the same or a different machine, also has a layered structure with
Business Logic Layer,
Service Layer and the
WCF Services, which are built on top of the service layer to expose these services to the clients using any supported WCF bindings. Typically internal clients would use a binary serialization format over the TCP or named pipes protocols for the best performance.
Service interfaces and data contracts (also known as Data Transfer Objects or DTO) in the
Service Layer are generated automatically from the Xomega service model and decorated with WCF attributes to enable exposing service contracts as
WCF Services. The service and endpoint configurations are also generated from the Xomega model.
The service implementation classes can also be initially generated from the Xomega service model, which speeds up the development process, but the developers need to implement any remaining service logic manually from that point on.
The service implementation classes use Entity Framework (EF) and LINQ to read the data from the database and persist the changes to the data. The Entity Data Model (EDM) is automatically generated from the Xomega object model and the classes for the corresponding entities are in turn generated from the EDM either by the built-in Visual Studio generator or by a T4 text template depending on whether you use the legacy Object Context or the latest DB context.
The generated entity classes can be extended to provide data validation, propagation and recalculation, which form the
Business Logic Layer. This allows for all this entity functionality to be reused across multiple services and ensure data validity and integrity regardless of which service is updating this data. Business Logic Layer may also include a number of background tasks and services that run in the middle tier either on a scheduled basis or in response to external events.
Data Tier
The data tier (also called persistence tier) is implemented as a relational SQL server database that is hosted in its own database server. Most of the communication with the database from the middle tier can be handled automatically by the Entity Framework and LINQ queries. However, the middle tier may call the database directly to invoke a stored procedure or run a SQL query.
The SQL server database may also have its own internal logic implemented using T-SQL in the stored procedures or triggers that runs directly in the database.
