WEB DEVELOPMENT

SYSTEM PHYSICAL ARCHITECTURE

The designed system follows a client-server architecture
with three tiers: the client, the web application server and the data
server tier. The data tier corresponds to the PHP backend, At the
top of this stack sits a pure PHP library, which we will distribute
as a Composer package. This library will provide an API similar
to what users have come to expect from the old mongo driver
(e.g., CRUD methods, database and collection objects, command
helpers) and we expect it to be a common dependency for most
applications built with MongoDB. This library will also
implement common specifications, in the interest of improving
API consistency across all of the drivers maintained by MongoDB
(and hopefully some community drivers, too).

Sitting below that library we have the lower level driver. This extension will effectively form
the glue between PHP and our system libraries ( libmongoc and libbson). This extension will
expose an identical public API for the most essential and performance-sensitive functionality:

 Connection management

 BSON encoding and decoding

 Object document serialization (to support ODM libraries)

 Executing commands and write operations

 Handling queries and cursors

By decoupling the driver internals and a high-level API into an extension and PHP libraries,
respectively, we hope to reduce our maintenance burden and allow for faster iteration on new
features. As a welcome side effect, this also makes it easier for anyone to contribute to the
driver. Additionally, an identical public API will make it that much easier to port an
application across PHP runtimes, whether the application uses the low-level driver directly or
a higher-level PHP library.

 GridFS is a great example of why we chose this direction. Although we implemented GridFS
in C for our old mongo driver, it is actually quite a high-level specification. Its API is just an
abstraction for accessing two collections: files (i.e. metadata) and chunks (i.e. blocks of data).
Likewise, all of the syntactic sugar found in the old mongo driver, such as processing
uploaded files or exposing GridFS files as PHP streams, can be implemented in pure PHP.
Provided we have performant methods for reading from and writing to GridFS' collections –
andDepartment of low
thanks to our CS&E, VVCE
level extensions, we will – shifting this API to PHP is win-win. Page 1
 WEB DEVELOPMENT

SYSTEM LOGICAL ARCHITECTURE

MVC is a software architectural pattern for implementing user interfaces on computers. It

divides a given application into three interconnected parts. This is done to separate internal
representations of information from the ways information is presented to, and accepted from
the user.

o MVC stands for "Model view And Controller".

o The main aim of MVC Architecture is to separate the Business logic &
Application data from the USER interface.
o Different types of Architectures are available. These are 3-tier Architecture,
N-tier Architecture, MVC Architecture, etc.
o The main advantage of Architecture is Reusability, Security and Increasing the
performance of Application.

Model:
o The Model object knows all about all the data that need to be displayed.
o The Model represents the application data and business rules that govern to an
Department of CS&E, VVCE Page 2
update of data.
 WEB DEVELOPMENT

o Model is not aware about the presentation of data and How the data will be display
to the browser.

View:
o The View represents the presentation of the application.
o View object refers to the model remains same if there are any modifications in the
Business logic.
o In other words, we can say that it is the responsibility of view to maintain consistency
in its presentation and the model changes.

Controller:
o Whenever the user sends a request for something, it always goes through Controller.
o A controller is responsible for intercepting the request from view and passes to the
model for appropriate action.
o After the action has been taken on the data, the controller is responsible for directly
passes the appropriate view to the user.
o In graphical user interfaces, controller and view work very closely together.

Department of CS&E, VVCE Page 3

Once the model finishes processing the request, the

 WEB DEVELOPMENT

controller selects the appropriate template and sends all

information related to the current request to the view. With this
information and some other obtained directly from the model, the
view generates a HTML document that is sent back to the client
via a HTTP response.

With this design, a new whole web page must be loaded

from the server every time the user wants to interact with the
system. This is known as a “thin client” design, because all the
logic is located in the server, leaving the client with the only task
of rendering the web page. In comparison with that, a “fat client”
hosts all the
logic of the system; hence Controller, View and Model are
located on the client side, leaving in the server just those parts of
the Model responsible for the security and management of
persistence.
Information can also be presented in an incremental way,
so that the user can start interacting with some elements of the
page while further information is being retrieved. Another
important fact is that traffic between the client and the system is
reduced to simple data with no presentation information, which
speeds up the communication with the system and decreases
network use.
While a fat client solves some external design issues, it
also creates several technical problems. Since the web page is
never reloading, the browser can no longer control the routing,
caching or history management of it. Therefore it is the
responsibility of the system to replace those functionalities that
the browser is unable to perform.

A mixed approach between a fat and a thin client can be the solution to improve the user experience
without giving up on the browser logic. The website can be divided into different contexts that offer
the user some common functionalities. Between contexts the web page is fully reloaded, while
operations within the contexts only update some parts of the page
Department of CS&E, VVCE Page 4
 WEB DEVELOPMENT

In order to facilitate understanding of the logical

architecture of the system, its design has been divided into two
different diagrams: the one corresponding to the scenario between
contexts and the one displaying the scenario within a context. The
former has already been explained before, so the following
explanation will focus on the differences and characteristics
between both scenarios.
Every time a new context is loaded or the user
interacts with the web page in some way, an event is fired
by HTML DOM9. The controller on the client side can
handle these events, in which case it gathers the required
information and requests the client-side model to validate
this information in order to avoid unnecessary calls to the
server.
If the validation was Stands for HTML Document
Object Model and is an object model and programming interface
for HTML, that defines all HTML elements as objects with
associated properties, methods and events. successful, the
controller sends the corresponding HTTP request to the server.

As well as before the controller requests the appropriate

changes to the model, but this time when the model finishes, the
controller generates JSON data using the information related to
the current request coming from the model. This JSON data is
sent back to the controller located on the client, which in turn
selects a template and sends this data to the view. With that, the
view generates a HTML fragment that uses to replace the
corresponding component on the web page.

Department of CS&E, VVCE Page 5