ODOT ASP.Net Web Development Architecture
Supplement 3:ODOT Web Application ArchitectureThe Ohio Department of Transportation (ODOT)Division of Information TechnologyODOT Default Web Application ArchitecturePrepared by the ODOT Division of Information Technology (DoIT)Contents TOC \o "2-4" \t "Heading 1,1" 1Introduction PAGEREF _Toc503336703 \h 21.1About This Document PAGEREF _Toc503336704 \h 22Architecture PAGEREF _Toc503336705 \h 32.1A Layered Approach PAGEREF _Toc503336706 \h 32.1.1User Interface Layer PAGEREF _Toc503336707 \h 32.1.2Domain Layer PAGEREF _Toc503336708 \h 32.1.3Service Layer PAGEREF _Toc503336709 \h 43Technologies PAGEREF _Toc503336710 \h 43.1Microsoft .NET Platform PAGEREF _Toc503336711 \h 43.1.1C# PAGEREF _Toc503336712 \h 43.1. PAGEREF _Toc503336713 \h 43.2AJAX PAGEREF _Toc503336714 \h 43.3Third Party Libraries PAGEREF _Toc503336715 \h 53.3.1Bing Maps API PAGEREF _Toc503336716 \h 53.3. – Lightweight Dependency Injection API PAGEREF _Toc503336717 \h 53.3.3ExtJs PAGEREF _Toc503336718 \h 53.3.4log4net PAGEREF _Toc503336719 \h 64Visual Studio Projects PAGEREF _Toc503336720 \h 65How To PAGEREF _Toc503336721 \h 65.1How to use the AdoTemplate in to perform database queries and transactions PAGEREF _Toc503336722 \h 65.2How to create a Visual Studio Project template automatically using the batch program PAGEREF _Toc503336723 \h 7IntroductionAbout This DocumentThe purpose of this document is to describe the default architecture used in development web applications at the Ohio Department of Transportation. Many of these same concepts apply to client/server based application development as well. ArchitectureA Layered ApproachThe default architectural approach used at ODOT for web applications involves a standard 3-tiered model for partitioning application logic. The three primary layers are User Interface Layer, Domain Layer, and Service Layer. The implementation of these various layers uses the C# programming language from the Microsoft .NET platform. The use of well defined application layers allows applications to be modified and extended without necessarily requiring significant code re-rewrites. For example, by having the data access logic located in the Service layers it makes it possible to replace the implementation without necessarily requiring any changes to the user interface.The following sections provide a brief description of these application layers and an indication of the type of application logic that should be implemented within each.User Interface LayerThis layer contains code that is specific to the user interface interactions (i.e. responding to user event, button clicks, click on links, form submission, etc). For web application, this logic will be implemented in C# as MVC Controllers returning Json data in response to AJAX calls from the client. When server side view logic is necessary then the system can leverage either the ASPX or (preferably) the Razor view engines. For the most part though, all view logic will be implemented using the ExtJs JavaScript framework and the server side controllers would be APIs returning Json/XML data in response to AJAX calls.Use of the ExtJs (5.x) Javascript user interface library is recommended for consistency in user interface development as well as for the rich set of user interface components offer by this library. The structure of the ExtJs JavaScript files should follow the Application Architecture recommended by the ExtJs vendor: of Web 2.0 style development techniques (i.e. AJAX based requests) to provide dynamic client side functionality is encouraged where appropriate. This is accomplished by using the AJAX libraries built into the ExtJs JavaScript framework.Note: One caveat to this is when building a feature rich JavaScript application it may be necessary for performance reasons to build a rich client side domain model in JavaScript. In this case these JavaScript classes would be considered an extension of the Domain layer as indicated below and could contain business logic that runs client side in the browser.Domain LayerThis is a Visual Studio class library project that compiles to a DLL called ODOT.<app name>.Domain.dll. The core of the application requirements will be modeled as Domain objects. Domain objects are C# classes that represent the key business concepts within the application (i.e. Users, Projects, Purchase Orders, Coordinates, etc.). This layer contains the primary business logic of the application (calculations, relationships among domain entities, etc). The exception to this would be business logic that spans multiple objects within a given database transaction in which case that logic would be located in a Service Layer method that would coordinate the logic required among the various domain entities.The Domain Layer is generated in its own .NET Assembly/dll which will contain all the domain entities for the application as well as interface definitions for the service layers (implemented as C# interface classes). The implementation of the service interfaces will reside in the Server Layer Assembly. By decoupling the domain layer from the service assembly, we can swap out different service implementation without affecting either the Domain Layer or the User Interface Layer.Service LayerThis is a Visual Studio class library project that compiles to a DLL called ODOT.<app name>.Service.dll. For ODOT web applications the Service Layer contains the transactional boundaries for the application and the data access logic (Create, Read, Update, and Delete logic). The Service Layer should be generated as its own .Net Assembly and it should provide an implementation of the service interfaces defined in the Domain Layer assembly. Most of the business logic of the application should be contains within the Domain entities and the service layer should defer to the domain entities where possible. The exception being when a business use case scenario requires coordination across multiple service interfaces within a single transaction. This type of business transaction would need to lie in the service layer itself.Note that the Service Layer implementation contains the data access logic for the application. This could involve accessing Web Services, FTP processes, flat file exchange, XML repositories, etc. Whatever the backend data sources is, this is the layer the logic should be implemented in TechnologiesMicrosoft .NET PlatformC#C# is the preferred language on the .NET platform. is the technology used to implement the web based User Interface Layer for all ODOT applications. The recommended approach is to separate the C# code into code behind files and leave the HTML and other user interface markup in the .ASPX file.AJAXAJAX (Asynchronous JavaScript and XML), or Ajax, is a group of inter-related web development techniques used for creating interactive web applications. A primary characteristic is the increased responsiveness of web pages achieved by exchanging small amounts of data with the server "behind the scenes" so that the entire web page does not have to be reloaded each time the user performs an action. This is intended to increase the web page's interactivity, speed, functionality, and usability.AJAX is asynchronous in that extra data is requested from the server and loaded in the background without interfering with the display and behavior of the existing page. JavaScript is the scripting language in which AJAX function calls are usually made. Data is retrieved using the XMLHttpRequest object that is available to scripting languages run in modern browsers. There is, however, no requirement that the asynchronous content be formatted in XML.AJAX is a cross-platform technique usable on many different operating systems, computer architectures, and web browsers as it is based on open standards such as JavaScript and the DOM. There are free and open source implementations of suitable frameworks and libraries such as the jQuery library. The use of AJAX techniques to deliver more response and robust web applications is encouraged and in some cases required (i.e. Microsoft Virtual Earth API).Third Party LibrariesBing Maps APIThe Bing Maps JavaScript API version 8 is the recommended API for web based mapping applications at ODOT. For more information on Bing Maps API see: – Lightweight Dependency Injection APIIn order to simplify some of the plumbing code necessary to “glue” domain objects together and to provide declarative transaction management the application should be deployed using the lightweight AOP container. allows declarative configuration of transactions without needing to use specific begin/end transaction logic as well as simplifying the use of in application code. It acts as an AOP container that allows dependent services to be configured declaratively.For additional information on see: is a JavaScript based collection of user interface components that leverage dynamic JavaScript to deliver a rich responsive user interface to end users. The library provides common user interface components such as grids, trees, dialog boxes, etc. As well as dynamic web layout management that does not have to be hand coded by the developer. Use if this library is highly recommend for all but the simplest of web applications.For additional information on ExtJs see: : ODOT currently uses the 5.x versions of ExtJs in all new web applications; however there are still many ODOT legacy systems that use the 3.x versions of this library.log4netLog4net is a tool to help the programmer output log statements to a variety of output targets. In case of problems with an application, it is helpful to enable logging so that the problem can be located. With log4net it is possible to enable logging at runtime without modifying the application binary. The log4net package is designed so that log statements can remain in shipped code without incurring a high performance cost. It follows that the speed of logging (or rather not logging) is crucial.At the same time, log output can be so voluminous that it quickly becomes overwhelming. One of the distinctive features of log4net is the notion of hierarchical loggers. Using these loggers it is possible to selectively control which log statements are output at arbitrary granularity.For more information on log4Net see: Studio ProjectsMicrosoft Visual Studio is the preferred development tool for developing web applications. The following sections describe a default solution template for a standard web application project including the layout of files and folders on the developer’s local machine. For more details related to structuring solutions and projects in Visual Studio see: (v=vs.110).aspxFor a description on how to setup a visual studio project using the libraries described in this document see \\Itcfs014\Common\Development\ ODOT Visual Studio Project Template.doc (Note: This document is based on an older version of Visual Studio but the project structure and project references are still the same.)How ToHow to use the AdoTemplate in to perform database queries and transactionsSee the Reference.chm user reference documentation. See specifically Chapter 20. Data access using .How to create a Visual Studio Project template automatically using the batch programA batch file has been created that runs a PowerShell script that automatically generates a standard Visual Studio Project template using the third party libraries and code structure described in this document. The batch file is located at:\\itcfs014\Common\Development\Tools\Scripts\create-odot-webapp.batJust pass in the name of the new application and it will create the directory structure and all the Visual Studio project structure files and library references. ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.