Client/Server desktop application represents a simpler version of multi-tier desktop application architecture where the business logic resides on the presentation tier, which communicates directly with the database.
This architecture is more appropriate for standalone applications that do not require any direct communications with external systems or any background services that have to run regardless of whether the desktop application is running for any users.
The following diagram demonstrates how the client-server 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, has a layered architecture where the UI layer interacts with the Service Layer wrapped around the Business Logic Layer.The UI layer 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 Service Layer 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. To make the generated forms calls the service layer directly the Service Invocation parameter of the generator should be set to “Direct”.
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. This allows providing alternative mock implementations of the services for testing purposes.
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.
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 presentation 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.
No comments:
Post a Comment