Scribd
Upload
101 views31 pages

MongoDB Mongoosess

MongoDB is a document-oriented, NoSQL database that uses dynamic schemas and stores data in BSON documents within collections rather than rows in tables. It supports indexing, validation rules, and atomic operations without transactions. The Mongoose object data modeling library provides an ORM-like interface for MongoDB that supports schemas, validation, querying, and more to simplify usage. Common web application architectures like n-tier, MVC, and 3-tier separate an application into layers (presentation, logic, data) or components (model, view, controller) to improve scalability, portability, and maintenance.

Uploaded by

kkk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
101 views31 pages

MongoDB Mongoosess

MongoDB is a document-oriented, NoSQL database that uses dynamic schemas and stores data in BSON documents within collections rather than rows in tables. It supports indexing, validation rules, and atomic operations without transactions. The Mongoose object data modeling library provides an ORM-like interface for MongoDB that supports schemas, validation, querying, and more to simplify usage. Common web application architectures like n-tier, MVC, and 3-tier separate an application into layers (presentation, logic, data) or components (model, view, controller) to improve scalability, portability, and maintenance.

Uploaded by

kkk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

MongoDB

Web Architecture
MongoDB
MongoDB is an open-source, NoSQL database that
uses a JSON-like (BSON) document-oriented
model.

Data is stored in collections (rather than tables).


- Uses dynamic schemas rather than a predefined
structure. Fields can be added/removed at will.
- Works with many programming languages.
- Caching: Most recent kept in RAM.
- No transactions, but allows atomic operations.
Example

Relational data model Data as documents

From: MongoDB_Architecture_Guide.pdf https://www.mongodb.com/json-and-bson


BSON?

BSON is Binary JSON

MongoDB encodes JSON documents in binary


format behind the scenes

BSON extends JSON to provide additional data


types (int, long, date, floating point)
Schema Enforcement?
JSON blobs provide flexibility but not what is always wanted

Consider: <h1>Hello {{person.informalName}}</h1>


- Good: typeof person.informalName == 'string' and length < something
- Bad: Type is 1GB object, or undefined, or null, or ...

Would like to enforce a schema on the data


- Can be implemented as validators on mutating operations

Mongoose - Object Definition Language (ODL)


- Take familiar usage from ORMs and map it onto Mongoose
- Effectively masks the lower level interface to MongoDB with something
that is friendlier
Document validation

Dynamic schemas provide great flexibility

Controls to maintain data quality are also important

MongoDB provides document validation within the


database
How does it work?
Using: var mongoose = require(mongoose');

1. Connect to the MongoDB instance

mongoose.connect('mongodb://localhost/myproject');

2. Wait for connection to complete: Mongoose exports an EventEmitter


mongoose.connection.on('open', function () {
// Can start processing model fetch requests
});

mongoose.connection.on('error', function (err) { });

Can also listen for connecting, connected, disconnecting, disconnected,


etc.
Schema defines collections
String, Number, Date, Buffer, Boolean
Array - e.g. comments: [ObjectId]
ObjectId - Reference to another object
Mixed - Anything
var userSchema = new mongoose.Schema({
first_name: String,
last_name: String,
emailAddresses: [String],
location: String
});
Schema allows secondary indexes and defaults

Simple index
first_name: {type: 'String', index: true}
Index with unique enforcement
user_name: {type: 'String', index:
{unique: true} }
Defaults
date: {type: Date, default: Date.now }
Secondary Indexes
Performance and space trade-off
- Faster queries: Eliminate scans - database just returns
the matches from the index
- Slower mutating operations: Add, delete, update must
update indexes
- Uses more space: Need to store indexes and indexes
can get bigger than the data itself
When to use
- Common queries spending a lot of time scanning
- Need to enforce uniqueness
Make model from schema
A Model in Mongoose is a constructor of objects a
collection May or may not correspond to a model of the
MVC

var User = mongoose.model('User', userSchema);

Create objects from Model


User.create({ first_name: 'Amy',
last_name: 'Pond'}, doneCallback);
function doneCallback(err, newUser) {
assert (!err);
console.log('Created object with ID', newUser._id);
}
Query collection
Returning the entire User collection

User.find(function (err, users) {


/*users is an array of objects*/ });

Returning a single user object for user_id

User.findOne({_id: user_id}, function (err, user) { /* ... */ });

Updating a user object for user_id


User.findOne({_id: user_id}, function (err, user) {
// Update user object
user.save();
});
Other query operations
var query = User.find({});
Projections
query.select(first_name last_name)
.exec(doneCallback);

Sorting
query.sort("first_name").exec(doneCallback);
Limits
query.limit(50).exec(doneCallback);
query.sort("-location")
Deleting objects from
collection

Deleting a single user with id user_id

User.remove({_id: user_id}, function (err) { } );

Deleting all the User objects

User.remove({}, function (err) { } )


Web Architectures

Higher level structures underlying a web ap

Made up of elements, their properties and the


relationships among elements
n-tier

Separate the components of a web app into


different tiers or layers
- Components of a web application are presentation,
processing logic, and data management
- Benefit of separating into tiers is all the good software
engineering properties
1-tier
All three layers are on the same machine and
presentation, logic and data are tightly connected.
- Scalability: Single processor, no separation, hard to
scale
- Portability: moving to a new machine, or changing
anything may mean major re-writes
- Maintenance: Changing one layer requires changing
other layers
2-tier
Database runs on a server separate from
application

Presentation and logic layers are tightly coupled

Can easily switch to a different database

Coupling of presentation and logic can lead to


heavy server load and network congestion.
3-tier
Each tier is separate with a clear interface between them.

Each tier can potentially run on a different machine

Client-server

Each tier is independent

Unconnected tiers should not communicate

Change in platform affects only that tier


Presentation layer

Provides user interface and interactions

Client-view or front-end

Shouldnt contain business logic or data access


code
Logic Layer

Set of rules for processing the data and


accommodates many individual users

No presentation or access code


Data Layer
Physical storage for data persistence

Manages access to the DB or file system

Also called the back-end

No presentation or business logic


The presentation layer is the static or dynamically
generated content rendered by the browser (front- end).

The logic layer is responsible for dynamic content


processing and generation, e.g. using Node.js, PHP,
Java EE, ASP.NET (middleware).

The data layer is the database, comprising the data sets


and data management system (back-end).
The main benefit of 3-tier is the independence of
layers, which means:
- Easier maintenance
- Reusable components
- Faster development (division of work)
Model View Controller

uses Controller manipulates

User Model

seen View updates


Model
state query state change
change notification
view selection

View Controller

user action

The model manages application state by responding to


requests for information about it state (from the view) or
instructions to change state (from the controller)
Model
state query state change
change notification
view selection

View Controller

user action

The view renders the model into a form suitable for


interaction (user interface). Multiple views can
exist for a single model given different contexts.
Model
state query state change
change notification
view selection

View Controller

user action

The controller receives user input and initiates a


response by making updates to the state of objects
in the model and selecting a view for the response.
In practice
The model is made up of the database (tables or
documents), session information (current state), and rules
governing transactions.

The view is the front-end website, made up of HTML,


CSS, and server-side templates.

The controller is any client-side scripting that manages


user interactions, HTTP request processing, and
business logic/preprocessing.
Benefits
Clarity of design, e.g., model methods providing an
API for data and state management.

Separation of concerns, where any component can


be easily used, replaced, or updated individually.

Parallel development, with construction and


maintenance based around adding parts in a
modular fashion and separation of concerns.

Distributable, ie., re-use of parts in different apps.


3-tier vs MVC

Communication: While in 3-tier the presentation


layer never communicates directly to the data layer
(only through the logic layer), in MVC all layers
communicate directly (triangle topology).

Usage: In 3-tier, the client, middleware, and data


tiers are on physically separate platforms, but in
MVC the model, view, and controller are together.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy