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
.
No comments:
Post a Comment