Classic ASP.NET web applications mostly run on the web server, which processes HTTP requests from the client browser and then either serves static resources, such as images, JavaScript or CSS files, or generates and returns dynamic resources, which are mainly HTML that may be mixed with dynamically generated JavaScript code and CSS classes. That HTML is then rendered on the client browser, which also executes any scripts within the HTML. Those scripts may in turn issue asynchronous AJAX requests to the server, which would return the response either as HTML snippets or in some other format.
Most of the UI logic is implemented on the web server in the middle tier along with the business logic for the application. The middle tier can access the database or any other external services to read or update the data.
The following diagram demonstrates how the ASP.NET web application architecture is implemented using the default Xomega solution template.
Presentation Tier
The presentation tier that runs in the browser consists primarily in rendering the HTML response from the web server, executing any scripts contained therein and applying the stylesheets. The scripts typically provide client side validations of the user input, but may do some basic DOM manipulation or issue additional server side AJAX requests to call a web service on the server side or make a partial page request.Middle Tier
Middle tier, which runs in the web server, has a layered structure with a Business Logic Layer, Service Layer and the Web Forms UI layer, which follows the Model-View-View Model (MVVM) development paradigm and in turn consists of Views, View Models and Code behind. All static resources such as HTML templates, JavaScript files, CSS and images are served by a standard Web Server like IIS.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 UI side or convert the data from one format to another, e.g. between the UI format and the internal values.
The actual UI logic is encapsulated in the Code behind that runs when the client sends GET or POST requests to the corresponding ASPX page (View) and acts as a Controller in the classic MVC approach. It instantiates a new View Model or retrieves the cached one from the current session 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 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 web bindings. These Xomega data objects may implement significant part of the UI behavior without any dependency on the web application, which means that you can reuse them in other types of clients such as desktop or Silverlight by simply binding them to a different XAML view.
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.
The page’s Code behind handles any user actions on the server side and calls the services provided by the Service Layer to read the data for the data objects and save the user updates from the data objects into the database.
All service interfaces and structures for 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. 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