Radixweb's Technical Architecture Document with HTML 5 MVC 5 and Bootstrap 3 version 1.1

www.radixweb.com

1

[email protected] Version 1.0 Confidential 25-04-2014

www.radixweb.com

TECHNICAL ARCHITECTURE For Microsoft .net Development

www.radixweb.com

2


www.radixweb.com

www.radixweb.com

3


www.radixweb.com

Table of Contents

Web Application Architecture..................................................................................................................... 4

Client-side Architecture .................................................................................................................................. 4

Server Side Architecture................................................................................................................................. 5

Technologies used in this architecture ...................................................................................................... 6

Web Application Architecture Goals .......................................................................................................... 7

Service Layer Architecture Goals .................................................................................................................. 8

Web API Design Rules: .................................................................................................................................... 8

Application Security ........................................................................................................................................ 9

Third Party Service Integration .................................................................................................................... 9

Presentation Layer ..................................................................................................................................... 10

Business Layer ............................................................................................................................................ 10

Data Acess Layer ......................................................................................................................................... 11

Reference: .................................................................................................................................................... 13

Radix Contact Information .......................................................................................................................... 13

www.radixweb.com

4


www.radixweb.com

Web Application Architecture

Client-side Architecture

In initial days, JavaScript was not considered as a general purpose application development language. Its

objective was to enhance the user experience in the browser by allowing dynamic HTML to be rendered and

changed without having to access a remote server.

This provides a perceived and real performance improvement, so rich user interfaces will minimize round-trips

to servers by implementing as much as possible in JavaScript and HTML5 elements on the client’s browser. To

take the advantage of its nature below is the proposed client-side architecture:

www.radixweb.com

5


www.radixweb.com

Server Side Architecture To start with, ASP.NET Web API is selected which is a popular framework that makes it easy to build HTTP

services, reaching a broad range of client side, including browsers and mobile devices which is quite essential

for any web application. And also ASP.NET Web API is one of the ideal platforms for building Restful

applications on the .NET Framework.

Below listed is the complete web application architecture diagram:

Web Application Architecture

a. based pMVC/Alarjs public-facing Web Application

www.radixweb.com

6


www.radixweb.com

Technologies used in this architecture

1) ASP.NET MVC 5

2) ASP.NET Web API 2.0

3) SQL Server 2012

4) Entity Framework (code-first) – 6.0.2

5) oData

6) oAuth (Json Web Token)

7) Managed Extensibility Framework

8) AngularJS

9) rxJS(custom build)

10) Bootstrap

11) Assorted libraries throughout

a. Moment (date handling in JS) b. ToastR(JSnotification display) c. Fluent Validation (rules engine)

Software Design Patterns, Principles and Programmingae Patterns and Principles we follow

in this architecture.

1. Software Pattern

a. Model View Controller

b. Repository Pattern

c. Unit Of Work Pattern

d. Concurrency Pattern

e. Dispose Pattern

2. Software Principles

a. Interface Segregation Principle

b. Single Responsibility Principle

c. Dependency Inversion Principle (DIP)

3. Software Programming a. cit Interface Implementation

b. Lambda Methods

c. Asynchronous Programming

www.radixweb.com

7


www.radixweb.com

Web Application Architecture Goals 1. Independence

a. Database

b. User Interface

c. Frameworks

2. Testability

a. Test components in isolation

Architecture Potential Solution

Pain Potential Solution

1 Redundant queries/DML Repository Pattern

2 Inability to unit test without hitting DB Repository Pattern

3 Difficulty styling server-side controls MVC, Angular, etc.

4 Excessive postbacks to support Web service

5 Fat controllers / Redundant Service Layer

6 Other clients desire service APIs

7 Data Access Performance Entity Framework(Code First) 6.0.2

8 Ugly data schema / Multiple Datasources Repository Pattern

9 Complex business logic Domain-Driven Design

10 Task based operations Async process

Flatter Model : Services and down-layers don’t call for deep, totally encapsulated business objects.

Strict Line of Seperation : Clients will ONLY communicate with services and have no knowledge of anything

else.

Testable Code : All code layers developed with testability in concerns in forefront.

Use of DI Throughout : Both business-side & client-side will get benefits from dependency injection.

Lack of Pass-Through : No unnecessary object just for data-passing purposes.

Multi-Use Entities : Entities on each side used for multiple purposes.

www.radixweb.com

8


www.radixweb.com

Service Layer Architecture Goals To separate the presentation layer from the business logic.

Shields the presentation layer from business logic complexity.

Supplies generic and common interface.

Keeps layers loosley coupled.

centralize handling cross-cutting concerns.

Service Layer Belongs to :

1. Security (authorization, managing user roles)

2. Logging

3. Searching

4. Embracement of HTTP

5. Notifications

6. Binding

7. Managing transactions

8. Data Validation

Web API Design Rules: Our Resource oriented design we follow some best practices:

URI Design: URI should point at Nouns (e.g. Resources). We prefer plurals, for example: /api/clients, /api/clients/123 Verbs: ASP.NET Web API makes heavy use of convention over configuration to lighten the workload involved in

creating web data services. We use verbs for according to the operation type.

Resource GET POST PUT DELETE

Clients Get List New Client Update Batch Error

Clients /123 Get Item Error Update Item Delete Item

Status Code: HTTP Status codes are three-digit numbers returned by servers that indicate the status

of web element. We use some status code.

Code Description Code Description

201 Created 304 Not Modified

401 UnAuthorized 403 Forbidden

500 Internal Error ---- --------------

Associations: Association should return its list of related objects or single object, for example:

FormatingResult:Formating result is a best part of Content Negotiation. We use accept header to determine

how to format.

Designing Result: We prefer camelCasing for returning json object, like:

{

companyName : “ABC Corp”,

www.radixweb.com

9


www.radixweb.com

cityName : “Melbourne”

}

ETags: Supports Strong and weak caching. ETags have request with if –None –match header tag. We use if-

none-match header tag on server for matching server entities data version.

HyperMedia: It is link for APIs. This links help developers to use APIs which becomes self- describing. This links will become Application state.

Application Security

We implement two type of security in this application :

1. Domain Security

2. User Security

We use json web token for accessing the application.

Purpose of Security Token(Json Web Token):

1. Contain information about issuer and subject

2. Signed(tamper proof & authenticity)

3. Typically contain an expiration time.

4. Client request a token.

5. An issuer issues a token. Token

Request and Response flow handle security, authorization and some other custom filters if needed. Refer

diagram:

Third Party Service Integration

We call some third party APIs through our business engine. Refer Below Diagram

www.radixweb.com

10


www.radixweb.com

Serving JSON over HTTP

Every Request and Response processed by JSON format.

Presentation Layer

Presentation Layer Architecture Goals

Presentation Layer Belongs to :

1. User Interface

2. View Model

3. Basic data validation

4. UI specific formatting

5. Logic to control user interface behaviours

a. Marshall data into/out of UI

b. Hide, show, and move components

c. Capture and display errors

Single Page Application :

1. Offers the richest user experience (Like Gmail)

2. One delivered view (from MVC)

3. Several sub-views (HTML sections)

4. All client side flipping Business Layer

Business Layer Architecture Goals

Separates concerns.

Abstract away complexity.

Support testing.

Minimize dependences.

Enable reuse.

www.radixweb.com

11


www.radixweb.com

Our Focus :saction Script

1. Simple Logic

2. OO paradigm

Table Module

1. Classes represents table(s)

2. DataTables, DataSets

Active Record

1. Simple & Obvious

2. Contains business logic

3. Often implemented using : Entity Framework

Domain Model

1. Manage Complexity

2. Leverage design Patterns

3. Speak business language

4. Abstract ugly DB schema

5. Reusable

Data Acess Layer

Data Access Layer Responsibilities

www.radixweb.com

12


www.radixweb.com

ORM

1. RDMS agnostic

2. Typesafe interface

3. Avoid writing SQL

4. SQL Injection protection

5. Security, performance, caching, mapping OOTB

Entity Framework

1. Async Query and Save adds support for the task-based asynchronous patterns.

2. Connection Resiliency enables automatic recovery from transient connection failures.

3. Code-Based Configuration gives the option of performing configuration.

4. Dependency Resolution support for the Service Locator pattern.

5. In Code First we can also use stored procedures for Insert/Update/Delete Operations.

6. SQL logging provides low-level building blocks for interception of EF operations with simple SQL

logging built on top.

7. Data Audit Logging

Repository Pattern

1. Clear separation of concerns

2. SWAP DB technology

3. Abstract multiple data sources

4. Support unit testing

5. Hides data access behind and interface.

6. Isolates domain objects from the database access code.

7. Object oriented view of the persistence layer.

8. Groups common queries.

9. Centralize query construction.

10. Encapsulates the objects persisted in a data store

and the operationsperformed over them.

11. Avoid duplicate queries

12. Strict control over queries

13. Object Oriented API

14. Centralizes access rules

15. Caching.

www.radixweb.com

13


www.radixweb.com

Reference:

Radix Contact Information

India Office 30/B Adarsh Society, Near Kaashi Parekh Complex, Swastik Char Rasta, C G Road, Ahmedabad -380009 Gujarat - India Phone: +91-79-26400685 VoIP: +1-718-715-1551

Radixweb's Technical Architecture Document with HTML 5 MVC 5 and Bootstrap 3 version 1.1

Documents

Transcript of Radixweb's Technical Architecture Document with HTML 5 MVC 5 and Bootstrap 3 version 1.1