Xomega Architecture for Silverlight Web Applications

Silverlight web applications are downloaded from the web server and executed inside the web browser by the Silverlight plug-in, which provides a restricted version of the .Net framework with limited access to the file system, threading model and other system resources.

In order to read data from the server and save changes Silverlight client makes WCF service calls using any WCF bindings that are supported by Silverlight. Typically the WCF services are hosted on the same web server and the client uses HTTP bindings and XML (SOAP) format.

The following diagram demonstrates how the Silverlight web application architecture is implemented using the default Xomega solution template.

Presentation Tier

Presentation tier, which runs in the browser, follows the Model-View-View Model (MVVM) development paradigms where the Views that represent the visual panels and controls 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 client navigates to the corresponding XAML view. 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 Silverlight application, which means that you can reuse them in other types of clients such as desktop 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 views with code behind for search and details pages 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 view and then update it and add the remaining 20% of functionality.

Middle Tier

The middle tier, which runs on the web-based application server, also has a layered structure with Business Logic Layer, Service Layer and the WCF Web Services, which are built on top of the service layer to expose these services over the web.

Static resources such as HTML pages, JavaScript files, CSS and images, as well as the actual Silverlight application package XAP, are served by a standard Web Server like IIS.

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 Web Services. The service and endpoint configurations as well as any IIS service host files 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
.

Xomega Architecture for Client/Server Desktop Applications

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.

Xomega Architecture for Multi-Tier Desktop Applications

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.