PROGRAMAÇÃO III

(ADSIS80_014)

Objetos x Registros

impedance mismatch

Incompatibilidade do modelo de dados relacional com o modelo OO

Objetos x Registros

impedance mismatch

De acordo com a documentação oficial do Hibernate diz que:

A impedância objeto-relacional, por vezes chamada de incompatibilidade de paradigmas, é apenas uma maneira elegante de dizer que modelos de objetos e relacionais não funcionam muito bem juntos.

Modelos de bancos de dados relacionais representam dados em formato tabular ao passo que linguagens como Java tratam isso de forma interconectada por meio de objetos

Objetos x Registros

impedance mismatch

  • Identidade
  • Estado
  • Comportamento
  • Encapsulamento

Objetos x Registros

impedance mismatch

  • Atomicidade
  • Consistência
  • Isolamento
  • Durabilidade

Objetos

Registros

X

ACID

  • Atômica: Todas as operações em uma transação são bem-sucedidas ou todas as operações são revertidas.
  • Consistente: Na conclusão de uma transação, o banco de dados é estruturalmente sólido.
  • Isolada: As transações não se enfrentam. O acesso contencioso aos dados é moderado pelo banco de dados, para que as transações pareçam ser executadas sequencialmente.
  • Durável: Os resultados da aplicação de uma transação são permanentes, mesmo na presença de falhas.

operações transacionais 

BASE

  • Disponibilidade básica: O banco de dados tem que estar ar a parte do tempo.
  • Estado leve: O armazenamento não precisam ser consistentes na gravação.
  • Consistência eventual: O armazenamento apresenta consistência em algum momento posterior (por exemplo, lazily at read time).

operações

trade-offs

ACID vs. BASE

Relacional x OLAP x NoSQL

ORM 

Object-Relational Mapping

ORM 

Object-Relational Mapping

  • Os ORM trabalham independentemente da aplicação e do banco de dados.
  • A camada de persistência deve intermediar a camada de dados e a camada de aplicação.
  • Esse tipo de solução tem como foco bases heterogêneas, ou gerenciar objetos de negócio distribuídos e persistentes

ORM 

Object-Relational Mapping

  • Possibilidade de uso de herança, ser capaz de criar hierarquias entre as entidades, e fazer uso de polimorfismo.
  • Suporte qualquer tipo de cardinalidade (1-1, 1-n, n-n)
  • Suporte a controle de transações (ACID x BASE)
    • atômicas, commit, rollback
  • Suporte a aggregates, equivalente aos recursos SQL de SUM, AVG, MIN, MAX e COUNT

Preocupações para se escolher um ORM

ORM 

Object-Relational Mapping

  • Suporte a DataBinding. É possível linkar os objetos mapeados a estruturas visuais da tela de forma que mudanças nos objetos se reflitam em mudanças visuais na tela e vice-versa? ---> MVC.
  • O framework tem recursos de Cache e otimização de Queries?
  •  Suporte otimista e pessimista para tratamento de concorrência

Preocupações para se escolher um ORM

ORM 

Object-Relational Mapping

  • Mapeamento reverso. É possível a partir de um banco de dados mapear minhas classes. "Engenharia reversa"

Preocupações para se escolher um ORM

ORM 

Object-Relational Mapping

  • Para garantir que todas as características do modelo de objetos sejam reproduzidas fielmente pelo banco de dados relacional, alguns aspectos merecem ser destacados.
  • Podemos tentar estabelecer uma analogia entre objetos e tabelas, e entre atributos e colunas.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Premissa: Mapear uma classe em uma tabela?

  • geralmente os atributos desse objeto são representados através de colunas na tabela

Regras de mapeamento...

essa não é uma regra que pode ser seguida ao pé da letra, pois existem outras considerações a serem feitas (tipos dos dados, tamanho dos campos, entre outras)

ORM 

Object-Relational Mapping

Todas as tabelas (ou relações) devem ter uma chave primária.

  • Em um sistema orientado a objetos, cada objeto é único.
  • Essa unicidade é garantida através da introdução de um “identificador de objetos” (OID – Object IDentifier).
  • Esse OID é gerado pelo sistema, não podendo ser alterado pelo usuário.
  • Seu valor não depende dos valores dos atributos do objeto.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Mapeamento de atributos.

  • Existem três tipos de atributos para serem mapeados.
    • 1º - Os atributos simples são mapeados para colunas.
    • 2º - Os atributos compostos podem ser mapeados em várias colunas.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Mapeamento de atributos.

  • Existem três tipos de atributos para serem mapeados.
    • 3º - Os atributos multivalorados devem ser mapeados em tabelas onde a chave primária é composta pela chave primária da tabela que representa a classe que contém o atributo multivalorado e pela chave primária que representa o atributo multivalorado.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Herança

  • Pode-se mapear este conceito de três formas.
    • 1º - Criar uma tabela para cada classe.
    • 2º - Criar uma única tabela para toda a hierarquia de classes.
    • 3º - Criar uma tabela para cada classe concreta.

Regras de mapeamento...

ORM 

Object-Relational Mapping

1º - Criar uma tabela para cada classe.

Regras de mapeamento... Herança

  • Na técnica de criação de uma tabela para cada classe, os atributos da tabela são os atributos específicos da classe e mais uma coluna de chave estrangeira que referencia a chave primária da tabela pai.
  • As desvantagens do uso dessa técnica é que são geradas muitas tabelas no banco de dados, fazendo com que haja uma demora maior para ler e gravar os dados. Por esse mesmo motivo, algumas consultas acabam sendo bastante dificultadas, obrigando a criação de views para agilizar o processo.

ORM 

Object-Relational Mapping

1º - Criar uma tabela para cada classe.

Regras de mapeamento... Herança

ORM 

Object-Relational Mapping

2º - Criar uma única tabela para toda a hierarquia de classes.

Regras de mapeamento... Herança

  • Nessa abordagem a classe raiz é tomada por base, pois é nela que todos os atributos são armazenados.
  • Essa técnica facilita as consultas, pois os dados de um objeto estão em uma única tabela.
  • O problema é que, potencialmente, há um desperdício de espaço no banco de dados. Além disso, a performance pode ser prejudicada.

ORM 

Object-Relational Mapping

2º - Criar uma única tabela para toda a hierarquia de classes.

Regras de mapeamento... Herança

ORM 

Object-Relational Mapping

3º - Criar uma tabela para cada classe concreta.

Regras de mapeamento... Herança

  • Nessa abordagem deve-se incluir em cada tabela tanto os atributos específicos, quanto os atributos herdados da classe que ela representa.
  • Como os dados de uma classe ficam todos em uma única tabela, as consultas são facilitadas.

ORM 

Object-Relational Mapping

3º - Criar uma tabela para cada classe concreta.

Regras de mapeamento... Herança

ORM 

Object-Relational Mapping

Associações Muitos-para-Muitos

  • Neste caso devemos criar uma tabela associativa em que a chave primária é composta pelas chaves primárias das tabelas associadas à famosa e já conhecida entidade ou tabela associativa.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Muitos-para-Muitos

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Muitos-para-Muitos com Classe de Associação

  • Neste caso, aplica-se a regra da associação muitos-para-muitos e os atributos da classe associativa permanecerão na tabela que é gerada para mapear a associação.

 

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Muitos-para-Muitos com Classe de Associação

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Muitos

  • Neste caso, a tabela cujos registros podem ser endereçados diversas (lado Muitos do relacionamento) vezes é a que herda a referência da tabela cuja correspondência é unitária (chave estrangeira (FK) que referencia a tabela de composição.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Muitos

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Muitos com Classe de Associação

  • Neste caso, aplica-se a regra da associação um-para-muitos e os atributos da classe associativa são herdados como atributos normais pela tabela que herda a chave estrangeira.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Muitos com Classe de Associação

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Nesse tipo de associação, deve optar por gerar
    • Uma única tabela no modelo relacional,
    • Gerar duas tabelas (uma para cada classe).

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Uma única tabela no modelo relacional
    • Os atributos da classe agregada devem ser colocados na mesma tabela da classe agregadora. Nessa técnica, a performance é melhor, pois é preciso acessar uma única tabela.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Uma única tabela no modelo relacional
    • Além disso, o objeto agregado é automaticamente excluído quando o objeto agregador é eliminado, não havendo a necessidade da implementação de triggers ou rotinas especiais na aplicação para garantir a consistência do banco de dados.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Uma única tabela no modelo relacional
    • A grande desvantagem dessa técnica é que a incorporação dos atributos aumenta a quantidade de páginas que são recuperadas em cada acesso à tabela.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Uma única tabela no modelo relacional

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Gerar duas tabelas (uma para cada classe).
    • Nessa opção, uma delas deve herdar como um atributo normal (chave estrangeira) a chave primária da outra tabela. Essa técnica facilita a manutenção das tabelas e torna a estrutura do banco de dados mais flexível.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Gerar duas tabelas (uma para cada classe).
    • Porém, as consultas necessitam de uma operação de junção (join) ou pelo menos dois acessos ao banco de dados. Se o acesso aos dados de ambas as tabelas não for muito freqüente, esta alternativa é aceitável, caso contrário, essa alternativa pode não ser a mais adequada.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Gerar duas tabelas (uma para cada classe).
    • Outra desvantagem de gerar uma tabela para cada classe é que para manter a consistência do banco de dados entre essas tabelas, por ocasião de operações de exclusão de objetos, é necessário implementar triggers ou rotinas especiais na aplicação.

Regras de mapeamento...

ORM 

Object-Relational Mapping

Associações Um-para-Um

  • Gerar duas tabelas (uma para cada classe).

Regras de mapeamento...

Driver

o mágico
$ npm install --save mysql2
  • Um driver é um componente de software que permite que uma aplicação interaja com um banco de dados. Para conectar com bancos de dados individuais, existem diversos drivers uma para cada SGBD. O driver fornece a conexão ao banco de dados e implementa o protocolo para transferir a consulta e o resultado entre cliente e banco de dados.

Driver

o mágico
const mysql = require('mysql2');

const connection = mysql.createConnection({
    host: "localhost",
    user: "root",
    password: "root",
    database: "teste"
});

connection.query(
    'SELECT * FROM users', (err, result, fields) => {
        console.log(fields);
        console.log(result);
    });

Consulta simples

Desafio Petshop

Modelar objetos com JS para representar o  atendimento de um Petshop.

CRUD

Create Read Update Delete

Desafio Petshop - Parte II

Mapear os objetos para persistir e recuperar no Petshop.
// TODO - Implementar métodos do CRUD - Create Read Update Delete

// CREATE => INSERT INTO telefone VALUES ...
// READ   => SELECT telefone VALUES ...
// UPDATE => UPDATE telefone SET ... WHERE ...
// DELETE => DELETE telefone WHERE ...

Petshop - init e

Estrutura

- public/
-- css/
--- styles.css

- src
-- routes.js
-- server.js

- views/
-- layout.ejs
--- pages/
---- home.ejs
$ mkdir petshop
$ npm install --save yarn -g

$ yarn init
# prencher dados

Petshop - Dependências

$ yarn add express
$ yarn add ejs
$ yarn add express-ejs-layouts
$ yarn add body-parser
$ yarn add nodemon -D

Petshop - Dependências

express É o pacote mais simples para criarmos as rotas do nosso app
ejs É o pacote responsável pela engine EJS
express-ejs-layouts Usamos ele para conseguirmos enviar dados para nossas páginas ejs pelo express.
nodemon Pacote usado para subir sua aplicação com a vantagem de que a cada vez que alterar ou criar um arquivo js ele reinicia automaticamente.
body-parser middleware para tratar as requisições antes de ser manipulada

Petshop - Dependências

"scripts": {
    "dev": "nodemon src/server.js"
},
"dependencies": {
  "body-parser": "^1.19.0",
  "ejs": "^3.0.1",
  "express": "^4.17.1",
  "express-ejs-layouts": "^2.5.0"
},
"devDependencies": {
  "nodemon": "^2.0.2"
}

package.json

Petshop - Projeto

const express = require('express')
const bodyParser = require('body-parser')
const expressLayouts = require('express-ejs-layouts')
const app = express()
const port = process.env.PORT || 3000
const routes = require('./routes')

src/server.js

Variáveis globais

Petshop - Projeto

app.set('view engine', 'ejs')     
app.use(expressLayouts)           
app.use(bodyParser.urlencoded()) 

app.use(express.static(__dirname + '/public'))

app.use(routes)

app.listen(port, () => {
    console.log(`Petshop is on http://localhost:${port}`)
})

src/server.js

Configurações

Petshop - Projeto

const express = require('express')
const routes = express.Router()

routes.get('/', (req, res) => {
  res.render('pages/home');
});

module.exports = routes;

src/routes.js

Rotas

Petshop - Projeto

<!doctype html>
<html lang="en">

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <meta name="description" content="Protótipo">
  <meta name="author" content="MentorsTec">
  <link rel="icon" href="/docs/4.0/assets/img/favicons/favicon.ico">

  <title>Petshop-ADS</title>

  <link rel="canonical" href="https://getbootstrap.com/docs/4.0/examples/jumbotron/">

  <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css"
    integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous">

  <style>

  </style>
</head>

<body>

  <nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark">
    <a class="navbar-brand" href="#">Cesumar</a>
    <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarsExampleDefault"
      aria-controls="navbarsExampleDefault" aria-expanded="false" aria-label="Toggle navigation">
      <span class="navbar-toggler-icon"></span>
    </button>

    <div class="collapse navbar-collapse" id="navbarsExampleDefault">
      <ul class="navbar-nav mr-auto">
        <li class="nav-item active">
          <a class="nav-link" href="/">Home <span class="sr-only">(current)</span></a>
        </li>
        <li class="nav-item">
          <a class="nav-link" href="sobre">Sobre <span class="sr-only">(current)</span></a>
        </li>
        <li class="nav-item">
          <a class="nav-link" href="/contato">Contato <span class="sr-only">(current)</span></a>
        </li>
      </ul>

    </div>
  </nav>

  <main role="main">

    <div class="jumbotron">
      <div class="container">
        <h1 class="display-3">Petshop</h1>
        <p>...</p>
      </div>
    </div>

    <div class="container">

      <%- body %>

    </div>
  </main>

  <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"></script>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js"
    integrity="sha384-ApNbgh9B+Y1QKtv3Rn7W3mgPxhU9K/ScQsAP7hUibX39j7fakFPskvXusvfa0b4Q"
    crossorigin="anonymous"></script>
  <script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js"
    integrity="sha384-JZR6Spejh4U02d8jOt6vLEHfe/JQGiRRSQQxSfFWpi1MquVdAyjUar5+76PVCmYl"
    crossorigin="anonymous"></script>

  <script src="https://cdn.jsdelivr.net/npm/sweetalert2@9"></script>

</body>

</html>

views/layout.ejs

Template base

Petshop - Projeto

<%- contentFor('body') %>

<h1>Clientes</h1>
<div class="row">
    <div class="col-xs-1-12 p-2">
        <div class="card">
            <img class="card-img-top" src="https://picsum.photos/id/237/200/300" alt="Card image cap">
            <div class="card-body">
                <h5 class="card-title">Henrique Vignando</h5>
                <p class="card-text">CPF/CNPJ: 070.824.859-48</p>
                <a href="#" class="btn btn-primary">Editar</a>
            </div>
        </div>
    </div>
</div>

views/page/home.ejs

Pagina usando template 

Petshop - Projeto

$ yarn dev

run...

Sequelize

  • Sequelize é um ORM  baseado em promessa (callback) para Node.js . Suporta PostgreSQL, MySQL, MariaDB, SQLite e Microsoft SQL Server. 
  • Migrations
  • Trabalha com bases legadas
  • ORM mais utilizado em Node.Js

https://sequelize.org/

Sequelize

  • Tipagem dos dados
  • Dialetos de DB
  • Definição de Modelos (Classes ->Entidades)
  • Finders dinâmicos, Queries e funções de operações
  • Relacionamentos
    • one-to-one
    • one-to-many
    • belongs-to-many
  • Controle de Transações
  • CRUD e bulk (em massa)
  • Hooks

Principais Características

Sequelize - Instalação Básica

$ npm install --save sequelize
$ npm install --save mysql2

Sequelize - Instalação

$ yarn add sequelize

# Instalação do driver
$ yarn add pg pg-hstore # Postgres
$ yarn add mysql2 # MySQL
$ yarn add mariadb # MariaDB
$ yarn add sqlite3 # SQLite
$ yarn add tedious # Microsoft SQL Server

$ yarn add sequelize-cli -D

Sequelize - Estrutura

- src
-- config
--- databas.js

-- database
--- migrations
--- index.js

- .sequelizerc

Sequelize - Config

module.exports = {
    dialect: 'mysql',
    host: 'localhost',
    username: 'root',
    password: 'root',
    database: 'petshop_ads',
    define: {
        timestamps: true,
        underscored: true,
    },
};

config/database.js

Configuração de conexão

Sequelize - Config

const Sequilize = require('sequelize');
const dbConfig = require('../config/database');

const connection = new Sequilize(dbConfig);

module.exports = connection;

database/index.js

Passando a conexão para nossa app

Sequelize - Config

const path = require('path')

module.exports = {
  config: path.resolve(__dirname, 'src', 'config', 'database.js'),
  'migrations-path': path.resolve(__dirname, 'src', 'database', 'migrations')
}

.sequelizerc

Configuração do Sequelize

Sequelize - Config

$ yarn sequelize migration:create --name=cria-cliente

Criando arquivo de migração

Sequelize - Config

'use strict';

module.exports = {
  up: (queryInterface, Sequelize) => {
    return queryInterface.createTable('clientes', {
      id: {
        type: Sequelize.INTEGER,
        primaryKey: true,
        autoIncrement: true,
        allowNull: false,
      },
      nome: {
        type: Sequelize.STRING,
        allowNull: false,
      },
      sobrenome: {
        type: Sequelize.STRING,
        allowNull: true,
      },
      email: {
        type: Sequelize.STRING,
        allowNull: false,
      },
      created_at: {
        type: Sequelize.DATE,
        allowNull: false,
      },
      updated_at: {
        type: Sequelize.DATE,
        allowNull: false,
      },
    });
  },

  down: (queryInterface, Sequelize) => {
    return queryInterface.dropTable('users');
  }
};

<timestemp>-cria-cliente.js

Criando arquivo de migração

$ yarn sequelize db:create
$ yarn sequelize db:migrate

Gerando banco e tabela no DB

Objeto Entidade

const { Model, DataTypes } = require('sequelize');
const connection = require('../database')

class Cliente extends Model {
  static init(sequelize) {
    super.init({
      nome: DataTypes.STRING,
      sobrenome: DataTypes.STRING,
      email: DataTypes.STRING,
    }, {
      sequelize,
    })
  }
}

Cliente.init(connection);
module.exports = Cliente;

Cliente.js

Criando arquivo de Classe

- src
-- models
--- Cliente.js

Rotas

const express = require("express");
const routes = express.Router();

const Cliente = require("./models/Cliente");

routes.get("/", async (req, res) => {
  const henrique = await Cliente.create({
    nome: "Henrique",
    sobrenome: "Vignando",
    email: "rickuev@gmail.com",
  });

  res.render("pages/home", {cliente: henrique});
});

module.exports = routes;

src/routes.js

Instanciando Cliente

Pages

<%- contentFor('body') %>

<h1>Clientes</h1>
<div class="row">
    <div class="col-xs-1-12 p-2">
        <div class="card">
            <img class="card-img-top" src="https://via.placeholder.com/250" 
                 alt="Card image cap">
            <div class="card-body">
                <h5 class="card-title">
                  <%= cliente.nome %> <%= cliente.sobrenome %> 
                 </h5>
                <p class="card-text"><%= cliente.email %> </p>
                <a href="#" class="btn btn-primary">Editar</a>
            </div>
        </div>
    </div>
</div>

views/page/home.ejs

Instanciando Cliente

Desafio Petshop - Parte III

Mapear -CRUD- os objetos (Cliente, Fornecedor, Endereço e Telefone) para persistir e recuperar no projeto NodeJs Petshop usando ORM Sequelize.

MVC - Model View Controller

Contexto - Arquitetura em camadas (Layering)

Benefícios importantes em dividir um sistema em camadas:

  • Entender uma única camada como um todo coerente sem conhecer sobre as outras camadas.
  • Substituir camadas por implementações alternativas do mesmo serviços básicos.
  • Minimiza dependências entre as camadas.
  • Camadas são bons locais para padronização.
  • Dado uma camada, pode-se usá-la para outros serviços de nível superior. 

Contexto - Arquitetura em camadas (Layering)

  • Exemplo: as camadas da Rede
    • Você pode entender como criar um serviço FTP sobre o TCP sem conhecer os detalhes de como a Ethernet funciona.
    • Um serviço FTP pode ser executado sem alterações por Ethernet, PPP ou qualquer outra empresa de cabo.
    • Se a empresa de cabo mudar seu sistema físico de transmissão, desde que faça o IP funcionar, não precisaremos alterar nosso serviço de FTP.
    • TCP e IP são padrões porque definem como suas camadas devem operar.
    • O TCP / IP é usado por FTP, telnet, SSH e HTTP. Caso contrário, todos esses protocolos de nível superior teriam que escrever seus próprios protocolos de nível inferior.

Contexto - Arquitetura em camadas (Layering)

Desvantagens da arquitetura em camadas:

  • Camadas encapsulam bem algumas coisas, mas não todas. Como resultado é a alterações em cascata.
    • Exemplo: um aplicativo corporativo em camadas é adicionar um campo que precisa ser exibido na interface do usuário, deve estar no banco de dados e, portanto, deve ser adicionado a todas as camadas intermediárias.

Contexto - Arquitetura em camadas (Layering)

Desvantagens da arquitetura em camadas:

  • Camadas extras podem prejudicar o desempenho. Em todas as camadas, as coisas normalmente precisam ser transformadas de uma representação para outra. Porém, o encapsulamento de uma função subjacente geralmente oferece ganhos de eficiência que mais do que compensam.
    • Exemplo: uma camada que controla as transações pode ser otimizada e tornar  rápido as consultas de banco de dados mais rápidas.

Contexto - Arquitetura em camadas (Layering)

A parte mais difícil de uma arquitetura em camadas é decidir quais camadas ter e qual deve ser a responsabilidade de cada camada.

Contexto - Arquitetura de Sistemas

Arquitetura de um sistema tem diversos elementos como:

  • elementos utilitários
  • elementos de interação
  • elementos que fazem parte do domínio do problema
  • elementos de conexão
  • elementos de persistência
  • entre outros...

Contexto - Arquitetura de Sistemas

  • Em arquitetura de sistemas definimos os elementos que precisarão ser utilizados no software e como eles se correlacionam (concerns).
  • Uma arquitetura complexa exige mais tempo para desenvolvimento.
  • Por isso algumas equipes definem um framework para uma determinada aplicação, assim é possível utilizar muitas coisas pré-prontas que facilitam o desenvolvimento.

História - Antigamente...

  • Arquiteturas de apenas uma camada eram comuns antigamente nos mainframes que centralizavam todo o processamento, persistência e interface do programa.
  • Outro exemplo, cada vez mais extinto em aplicações corporativas, são os programas Desktop puramente locais. Certamente, usar apenas uma camada tem a vantagem de diminuir a latência e melhorar a performance, já que não há a necessidade de efetuar requisições na rede para buscar informações.

História - Padrões de Projeto

  • O Engenheiro Civil Christopher Alexander em 1977 publicou um catálogo com mais de 250 padrões para a arquitetura civil, que discutiam questões comuns da arquitetura, descrevendo em detalhe o problema e as justificativas de sua solução.
  • Christopher Alexander descobriu que diminuindo o foco, ou seja, procurando estruturas que resolvam problemas similares, ele pode discernir similaridades entre projetos de alta qualidade. Ele chamou essas similaridades de “padrões”.
  • Através do trabalho de Alexander, profissionais da área de desenvolvimento de software utilizaram tais conceitos para iniciar as primeiras documentações de padrões de projetos, tornando-as acessíveis para toda a área de desenvolvimento.

É considerado como um padrão de projeto, uma solução já testada e documentada que possa resolver um problema específico em projetos distintos.

  • Trygve Reenskaug , funcionário Xerox, iniciou em 1979 o que viria a ser o nascimento do padrão de projeto MVC.
  • A implementação original foi descrita no artigo “Applications Programming in Smalltalk-80: How to use Model-View-Controller”.
  • A ideia de Reenskaug gerou um padrão de arquitetura de aplicação cujo objetivo é separar o projeto em três camadas independentes, que são o modelo, a visão e o controlador

História - Padrões de Projeto

Martin Fowler - GUI e MVC

  • Forms and Controls
  • Model View Controller
  • VisualWorks Application Model
  • Model-View-Presenter (MVP)
  • Humble View

Padrão de Projetos e Arquiteturas

  • O termo padrões de projeto ou Design Patterns, descreve soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos.
  • Padrões de projeto são estabelecidos por um nome, problema, solução e consequências.

Padrão de Projetos e Arquiteturas

  • O problema descreve quando devemos aplicar o padrão, qual o problema a que se refere e seu contexto.
  • A solução descreve os elementos que fazem parte da implementação, as relações entre os elementos, suas responsabilidades e colaborações.
  • Uma solução deve descrever uma implementação abstrata de um problema e como resolvê-lo.
  • As consequências são os resultados, vantagens e desvantagens ao utilizar o padrão, importantes para avaliar as alternativas descritas bem como proporcionar uma ideia de custos e benefícios ao aplicá-lo.

Padrão de Projetos e Arquiteturas

O uso de algum padrão de projeto pode trazer alguns benefícios:

  • Aumento de produtividade
  • Uniformidade na estrutura do software
  • Redução de complexidade no código
  • As aplicações ficam mais fácies de manter
  • Facilita a documentação
  • Estabelece um vocabulário comum de projeto entre desenvolvedores

Padrão de Projetos e Arquiteturas

Mais benefícios:

  • Permite a reutilização de módulos do sistema em outros sistemas;
  • É considerada uma boa prática utilizar um conjunto de padrões para resolver problemas maiores que, sozinhos, não conseguiriam;
  • Ajuda a construir softwares confiáveis com arquiteturas testadas;
  • Reduz o tempo de desenvolvimento de um projeto.

Conceitos - antes do MVC

Acoplamento e Coesão

  • Acoplamento: mede o grau de interdependência entre módulos
  • Coesão: medida da funcionalidade de um módulo; o quanto ele realiza uma tarefa específica

Engenharia de Software - 7.ed.: Os Paradigmas Clássico e Orientado a Objetos - Yourdon, Constantine e Myers

Conceitos - antes do MVC

Acoplamento e Coesão

Acoplamento: “O acoplamento é uma medida da interconexão entre os módulos de uma estrutura de software, depende da complexidade de interface entre módulos”;

Coesão: "Um módulo coeso executa uma única tarefa dentro do procedimento de software, exigindo pouca interação com procedimentos executados em outras partes de um programa."

PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software-8ª Edição. McGraw Hill Brasil, 2016.

Conceitos - antes do MVC

Acoplamento e Coesão

Conceitos - MVC

  •  O principal conceito do modelo MVC é utilizar uma solução já definida para separar partes distintas do projeto reduzindo suas dependências ao máximo.
  • O MVC possibilita a divisão do projeto em camadas muito bem definidas. Cada uma delas, o Model (Modelo), a View (Visão) e o Controller (controlador), executa o que lhe é definido e nada mais do que isso.

Conceitos - MVC

  • A utilização do padrão MVC trás como maior benefício isolar as regras de negócios da lógica de apresentação, a interface com o usuário. Isto possibilita a existência de várias interfaces com o usuário que podem ser modificadas sem que haja a necessidade da alteração das regras de negócios, proporcionando assim muito mais flexibilidade e oportunidades de reuso das regras de negócio.

  • O padrão MVC pode ser utilizado em vários tipos de projetos como, por exemplo, desktop, web e mobile.
  • A comunicação entre interfaces e regras de negócios é definida através de um controlador. É a existência deste controlador que torna possível a separação entre as camadas.

Conceitos - MVC

  • O MVC foi desenvolvido para mapear o método tradicional de entrada, processamento, e saída.

Conceitos - MVC

Conceitos - MVC - Objetos

Controlador (Controller)

  • Ele é responsável por interpretar as entradas (mouse, teclado, requisição, etc.) enviado pelo usuário/cliente e mapear essas ações em comandos que são enviados para o modelo (Model) e/ou para a janela de visualização (View) para executar a operação apropriada.
  • Os pontos de mapeamento são comumente chamados de actions.
  • Existem duas formas  implementar os controladores:
    • Action-based
    • Component-based

Conceitos - MVC - Objetos

Controlador (Controller)

  • Action-based
    • ​trabalha orientado a requisições e respostas com características sem estado (stateless) para aproveitar melhor a Web e outras ferramentas que giram em torno do HTTP, além de garantir escalabilidade e disponibilidade mais facilmente
  • Component-based
    • têm como objetivo trazer características do desenvolvimento Desktop para o desenvolvimento Web. Programa-se orientado a componentes ricos e reaproveitáveis, com um modelo de tratamento de eventos robusto e manutenção do estado das telas (stateful).

Conceitos - MVC - Objetos

Visão (View)

  • A responsabilidade da visão é gerencia a área de apresentação do sistema
  • Também é responsável por apresentar as informações para o usuário através de uma combinação de gráficos e textos.
  • A visão não deve conhece o comportamento da aplicação, tudo que ela realmente faz é receber instruções do controle e informações do modelo e então exibir elas.
  • A visão também se comunica de volta com o modelo e com o controlador para reportar o seu estado, caso necessário no modelo stateful.

Conceitos - MVC - Objetos

Modelo (Model)

  • A responsabilidade do modelo é gerenciar um ou mais elementos de dados.
  • Ele responde a perguntas sobre estado dos dados e responde a instruções para mudança desse estado.
  • O modelo sabe deve conter a regra de negócio e é a principal estrutura computacional da arquitetura, pois é ele quem modela o problema que está se tentando resolver.

Conceitos - MVC - Objetos

Conceitos - MVC - Objetos

Uma possível implementação de Model View Controller para aplicações Web.

Outras técnicas - MTV

Outras técnicas - MTV

  • Model: É a camada de acesso a base de dados;
  • Template: É a camada de visualização das informações;
  • View: Esta camada é responsável pelas as regras de negócios do sistema Django.
Padrão MVC Padrão MTV
Model(MVC) Model(MTV)
View(MVC) Template(MTV)
Controller(MVC) View(MTV)

Outras técnicas - MVP

  • O MVP (Model View Presenter) quebra o Controller de modo que o acoplamento de View para action pode ocorrer sem amarrá-lo ao restante das responsabilidades do Controller. 

Outras técnicas - MVP

  • Model
    • Igual ao MVC / Nenhuma mudança
  • View
    • ​A única alteração aqui é que a action agora é considerada parte da View. A boa prática é ter uma action implementando uma interface de exibição para que o Presenter tenha uma interface para codificar
  • Presenter
    • ​Este é essencialmente o Controller do MVC, exceto por ele não estar vinculado a View, apenas a uma interface, com isto ele não mais gerencia o tráfego de solicitações recebidas, como é feito no Controller. 

Outras técnicas - MVVM

  • MVVM (Model View ViewlModel) trabalhar com data binding, e tem como benefícios testes mais fáceis e modularidade, ao mesmo tempo que reduz a quantidade de código que temos que escrever para conectar o Model com a View.
  • Suporta ligação bidirecional entre View e ViewModel, com isto nos permite ter propagação automática de mudanças.

Outras técnicas - MVVM

  • Model
    • Igual ao MVC e MVP / Nenhuma mudança
  • View
    • A View liga-se a variáveis ​Observable ​​e ações expostas pelo ViewModel de forma flexível.
  • ViewModel
    • O ViewModel é responsável por expor métodos, comandos e propriedades que mantém o estado da View, assim como manipular o Model com resultados de ações da View e preparar dados Observable necessários para a exibição.

MVC - Implementação

Concorrência

  • Introdução
  • Problemas
  • Isolamento e Imutabilidade
  • Controle Otimista e Pessimista
    • Impedindo leituras inconsistentes
    • Deadlock
  • Multithreading no NodeJS

Concorrência

  • A concorrência é um dos aspectos mais complicados do desenvolvimento de software. Sempre que houver vários processos ou threads manipulando os mesmos dados, você terá problemas de concorrência.
  • É difícil pensar em concorrência, pois é difícil enumerar os possíveis cenários que podem causar problemas.

  • Uma boa razão pela qual os desenvolvedores  não preocupam tanto com concorrência é por conta dos os gerenciadores de transações (ex. Banco de dados).

Concorrência - Introdução

  • Perda de Atualizações (Lost updates) nos CVS: digamos que Martin edite um arquivo para fazer algumas alterações no método checkConcurrency - uma tarefa que leva alguns minutos. Enquanto ele faz isso, David altera o método updateImportantParameter no mesmo arquivo. David inicia e termina sua alteração muito rapidamente, tão rapidamente que, embora ele comece depois de Martin, ele termina antes dele. Quando Martin leu o arquivo, ele não incluía a atualização de David; portanto, quando Martin escreve no arquivo, ele sobrescreve a versão de David e a atualização de David se perde para sempre.

Concorrência - Problemas

  • Leitura inconsistente (Inconsistent read) ocorre quando você lê duas coisas que são informações corretas, mas não corretas ao mesmo tempo. Martin quer saber quantas classes existem no pacote de concorrência, que contém dois subpacotes para bloqueio e multifase. Martin olha no pacote de bloqueio e vê sete classes. Nesse ponto, ele recebe um telefonema de Roy sobre alguma pergunta obscura. Enquanto Martin atende o telefone, David termina de lidar com esse bug no código de bloqueio de quatro fases e adiciona duas classes ao pacote de bloqueio e três classes às cinco que estavam no pacote multifásico. Ao terminar o telefonema, Martin olha no pacote multifásico para ver quantas classes existem e vê oito, produzindo um total geral de quinze.

Concorrência - Problemas

  • Infelizmente, quinze classes nunca foram a resposta certa. A resposta correta foi doze antes da atualização de David e dezessete depois. Qualquer resposta teria sido correta, mesmo que não fosse atual, mas quinze nunca foram corretas. Esse problema é chamado de leitura inconsistente porque os dados que Martin leu eram inconsistentes.

Concorrência - Problemas

  • Esses dois problemas causam uma falha de corretude (ou segurança) e resultam em comportamento incorreto que não teria ocorrido sem duas pessoas tentando trabalhar com os mesmos dados ao mesmo tempo.

  • O problema essencial de qualquer programação concorrente é que não basta se preocupar com a corretude; você também precisa se preocupar com a vivacidade: quanta atividade concorrente pode continuar. Muitas vezes, as pessoas precisam sacrificar alguma corretude para ganhar mais vivacidade, dependendo da seriedade e probabilidade das falhas e da necessidade de as pessoas trabalharem em seus dados concorrentemente.

Concorrência - Problemas

  • Os problemas de concorrência já existem há algum tempo, e já existem várias soluções.

  • Para aplicativos corporativos, duas soluções são particularmente importantes: isolamento e imutabilidade

Concorrência - Isolamento e Imutabilidade

  • Problemas de concorrência ocorrem quando mais de um agente ativo, como um processo ou encadeamento, tem acesso ao mesmo pedaço de dados. Uma maneira de lidar com isso é o isolamento: particione os dados para que qualquer parte deles possa ser acessada apenas por um agente ativo.

  • Os processos funcionam assim na memória do sistema operacional: O sistema operacional aloca memória exclusivamente para um único processo, e somente esse processo pode ler ou escreva os dados vinculados a ele.

Concorrência - Isolamento e Imutabilidade

  • Um bom design de concorrência é encontrar maneiras de garantir que o máximo de programação possível seja feito em uma região isolada de concorrência.

Concorrência - Isolamento e Imutabilidade

  • Outro problema é se os dados compartilhandos puderem ser modificados.

  • Uma maneira de evitar conflitos de concorrência são dados imutáveis.

  • Ao identificar alguns dados imutáveis, ou pelo menos imutáveis ​​quase o tempo todo, podemos tranquilizar as preocupações de concorrência e compartilhá-los amplamente.

Concorrência - Isolamento e Imutabilidade

Concorrência - Controle Otimista e Pessimista

  • O que acontece quando temos dados mutáveis que não podemos isolar? Em termos gerais, existem duas formas de controle de concorrência que podemos usar: otimista e pessimista.

Concorrência - Controle Otimista e Pessimista

  • Vamos supor que Martin e David desejem editar o arquivo do cliente ao mesmo tempo.

  • Com o bloqueio otimista, os dois podem fazer uma cópia do arquivo e editá-lo livremente. Se Davi for o primeiro a terminar, ele poderá verificar seu trabalho sem problemas. O controle de simultaneidade entra em ação quando Martin tenta confirmar suas alterações. Nesse ponto, o sistema de controle do código-fonte detecta um conflito entre as alterações de Martin e as de David. O comprometimento de Martin é rejeitado e cabe a ele descobrir como lidar com a situação.

Concorrência - Controle Otimista e Pessimista

  • Com o bloqueio pessimista, quem faz o check-out do arquivo primeiro impede que outras pessoas o editem. Portanto, se Martin for o primeiro a fazer o check-out, David não poderá trabalhar com o arquivo até que Martin termine e confirme suas alterações.

Concorrência - Controle Otimista e Pessimista

  • Uma maneira de pensar sobre isso é que um bloqueio otimista é sobre detecção de conflitos, enquanto um bloqueio pessimista é sobre prevenção de conflitos.

  • Ambas as abordagens têm seus prós e contras.

  • O problema com o bloqueio pessimista é que ele reduz a simultaneidade. Enquanto Martin está trabalhando em um arquivo, ele bloqueia, então todo mundo tem que esperar

Concorrência - Controle Otimista e Pessimista

  • Bloqueios otimistas permitem que as pessoas progridam muito melhor, porque o bloqueio é mantido apenas durante a confirmação. O problema com eles é o que acontece quando você entra em conflito. Basicamente, todo mundo após a confirmação de David precisa verificar a versão do arquivo que David fez check-in.

Concorrência - Controle Otimista e Pessimista

  • A essência da escolha entre bloqueios otimistas e pessimistas é a frequência e a gravidade dos conflitos.

  • Se os conflitos são suficientemente raros, ou se as consequências não são um grande problema, você deve escolher bloqueios otimistas, pois eles oferecem melhor concorrência e geralmente são mais fáceis de implementar.

  • No entanto, se os resultados de um conflito forem dolorosos para os usuários, você precisará usar uma técnica pessimista.

Concorrência - Impedindo leituras inconsistentes

  • Considere esta situação. Martin edita a classe Customer, que faz chamadas na classe Order. Enquanto isso, David edita a classe Order e altera a interface. David compila e faz commit; Martin então compila e faz commit. Agora, o código compartilhado está quebrado porque Martin não percebeu que a classe Order foi alterada depois da alteração dele. Alguns sistemas de controle de código-fonte detectam essa leitura inconsistente, mas outros exigem algum tipo de disciplina manual para reforçar a consistência, como atualizar seus arquivos do branch antes de fazer o commit.

Concorrência - Impedindo leituras inconsistentes

  • Em essência, esse é o problema de leitura inconsistente e geralmente é fácil ocorrer, porque a maioria das pessoas tende a se concentrar nas atualizações perdidas como o problema essencial na concorrência

  • Os bloqueios pessimistas lidam com esse problema por meio de bloqueios de leitura e gravação

    • Para ler dados, você precisa de um bloqueio de leitura (ou compartilhamento)

    • Para gravar dados, você precisa de um bloqueio de gravação (ou exclusivo)

Concorrência - Impedindo leituras inconsistentes

  • Bloqueios otimistas geralmente baseiam sua detecção de conflito em algum tipo de marcador de versão nos dados

    • Pode ser um marcação de data/hora ou um contador sequencial

    • Para detectar atualizações perdidas, o sistema verifica se o marcador de versão da sua atualização com o marcador de versão dos dados compartilhados. Se eles são iguais, o sistema permite a atualização e atualiza o marcador da versão

    • A detecção de uma leitura inconsistente é essencialmente semelhante, todos os dados lidos também precisam ter seu marcador de versão comparado com os dados compartilhados. Quaisquer diferenças indicam um conflito.

Concorrência - Impedindo leituras inconsistentes

  • Outra maneira de lidar com problemas de leitura inconsistentes é usar as leituras temporais

    • Estes prefixam cada leitura de dados com algum tipo de carimbo de data/hora ou rótulo imutável, e o banco de dados retorna os dados como estavam de acordo com esse horário ou rótulo.

    • Poucos bancos de dados têm algo parecido com isso, mas os desenvolvedores geralmente se deparam com isso nos sistemas de controle de código-fonte

Concorrência - Impedindo leituras inconsistentes

  • O problema é que a fonte de dados precisa fornecer um histórico temporal completo das mudanças, o que leva tempo e espaço para processar

  • Isso é razoável para o código fonte, mas é mais difícil e mais caro para bancos de dados.

Concorrência - Deadlock

  • Um problema específico com técnicas pessimistas é o deadlock

  • Digamos que Martin comece a editar o arquivo Cliente e David comece a editar o arquivo Pedido. David percebe que, para concluir sua tarefa, ele também precisa editar o arquivo Cliente, mas Martin tem um bloqueio para que ele tenha que esperar. Então Martin percebe que precisa editar o arquivo Pedidos, que David bloqueou. Eles agora estão em um deadlock - nenhum deles pode progredir até que o outro seja concluído.

  • Descritos dessa maneira, os deadlocks parecem fáceis de evitar, mas podem ocorrer com muitas pessoas envolvidas em uma cadeia complexa, e os torna mais complicados.

Concorrência - Deadlock

  • Existem várias técnicas que você pode usar para lidar com conflitos. Uma é ter um software que possa detectar um deadlock quando ocorrer.
  • Nesse caso, você escolhe uma vítima, que tem que jogar fora seu trabalho e suas madeixas para que os outros possam progredir.
  • A detecção de deadlock é muito difícil e causa é ruim para às vítimas.

Concorrência - Deadlock

  • Uma abordagem semelhante é conceder um limite de tempo a cada bloqueio. Uma vez atingido esse limite, você perde seus bloqueios e seu trabalho - essencialmente se tornando uma vítima. 
  • Os tempos limites são mais fáceis de implementar do que um mecanismo de detecção de conflito, mas se alguém reter bloqueios por um tempo, algumas pessoas serão vitimadas quando na verdade não houver um conflito.

Concorrência - Deadlock

  • Outras abordagens é tentar impedir que os deadlocks ocorram.
  • Os bloqueios ocorrem essencialmente quando as pessoas que já possuem bloqueios tentam obter mais (ou atualizar de bloqueios de leitura para gravação).
  • Assim, uma maneira de impedi-los é forçar as pessoas a adquirir todos os bloqueios de uma só vez no início de seu trabalho e depois impedi-los de ganhar mais.

Concorrência - Deadlock

  • Pode-se forçar um pedido sobre como todos recebem bloqueios.
  • Um exemplo pode ser sempre obter bloqueios em arquivos em ordem alfabética. Dessa forma, depois que David tiver um bloqueio no arquivo Pedido, ele não poderá tentar bloquear o arquivo Cliente, porque é mais cedo na sequência. Nesse ponto, ele se torna essencialmente uma vítima.

  • Outra alternativa seria, se Martin tentar adquirir uma lock e David já tiver uma, Martin se tornará automaticamente uma vítima. É uma técnica drástica, mas é simples de implementar. E, em muitos casos, esse esquema funciona muito bem.

Concorrência - Deadlock

  • Uma estratégia conservadora, poderia usar vários esquemas.
  • Por exemplo, você força todos a obter todos os bloqueios no início, mas adiciona um tempo limite no caso de algo dar errado.
  • Isso pode parecer usar cinto, mas esse conservadorismo costuma ser sábio em relação aos deadlocks, porque são coisas incômodas e fáceis de errar.

Concorrência - Deadlock

  • É muito fácil pensar que se tem um esquema à prova de deadlock e depois encontrar uma cadeia de eventos que não considerou.
  • Como resultado, preferimos esquemas muito simples e conservadores para o desenvolvimento de aplicativos corporativos.
  • Eles podem causar vítimas desnecessárias, mas isso geralmente é muito melhor do que as consequências de perder um cenário de conflito.

Sistemas (Aplicações) Distribuídos 

Sistemas (Aplicações) Distribuídos 

Um sistema distribuído é aquele no qual os componentes localizados em computadores interligados em rede se comunicam e coordenam suas ações apenas passando mensagens

 Coulouris et al. 2007

Sistemas (Aplicações) Distribuídos 

  • Definição
  • Características
  • Microserviços
  • Web services e API’s

Sistemas (Aplicações) Distribuídos 

Definição

  • Três propriedades importantes dos Sistemas Distribuídos (SD)
    • Concorrência de componentes
    • Falta de um relógio global
    • Falhas de componentes independentes
  • A implementação com sucesso de aplicações para Sistemas Distribuídos deve levar em consideração os itens acima.

Sistemas (Aplicações) Distribuídos 

Definição

  • Os sistemas distribuídos foram inicialmente propostos para o compartilhamento de recursos (arquivos, impressoras, etc)
  • A lista destes recursos foi amplamente estendida ao longo do tempo
    • Serviços
    • Componentes
    • Processamento
    • Comunicação
    • Objetos
    • Dados

Sistemas (Aplicações) Distribuídos 

Características

  • Heterogeneidade
  • Escalabilidade
  • Segurança
  • Tratamento de Falhas
  • Concorrência
  • Transparência

Sistemas (Aplicações) Distribuídos 

Heterogeneidade

  • Diferentes tipos de entidades computacionais, controladas por diferentes SO's e conectadas por diferentes tipos de rede podem compor um sistema distribuído.
  • Os protocolos de rede são usados para tornar a comunicação entre essas entidades transparente. No entanto, algumas aplicações requerem o uso de um Middleware para assegurar a coerência na comunicação.

Sistemas (Aplicações) Distribuídos 

Escalabilidade

  • Um SD é um sistema aberto. Isto significa que está sujeito a modificações ao longo do tempo.
  • A qualquer momento novas entidades podem ser incorporadas ao sistema, assim como outras entidades podem deixar de existir.
  • O mesmo vale para usuários do sistema e suas requisições.
  • Toda essa dinamicidade deve ser considerada ao implementar um SD.

Sistemas (Aplicações) Distribuídos 

Segurança

  • Esta certamente é uma das propriedades que mais causa preocupações aos usuários de SD.
  • O compartilhamento de recursos faz com que estes sejam visíveis a outros usuários do sistema, no entanto, eles devem ser protegidos
    de acessos indevidos.
  • Mecanismos de privilégios de usuário e criptografia são os modos mais usados para garantir a segurança nos SD.

Sistemas (Aplicações) Distribuídos 

Tratamento de falhas

  • Os elementos de um SD estão sujeitos a falhas (como qualquer outra entidade computacional).
  • Quando tais falhas forem identificadas, elas devem ser reportadas ao usuário e tratadas, a fim de manter o sistema coerente e confiável.

Sistemas (Aplicações) Distribuídos 

Concorrência

  • Por existirem diversos elementos em um SD, é possível que múltiplas requisições ou múltiplos acessos sejam realizados ao mesmo recurso,
    no mesmo instante de tempo.
  • A implementação do sistema deve garantir que todas os acessos/requisições sejam respondidos (mesmo que a resposta seja negativa).

Sistemas (Aplicações) Distribuídos 

Transparência

  • O principal objetivo de um SD é acessar recursos ao longo do sistema, como se fossem locais (um único sistema).
  • Essa característica tornou os SD acessíveis a todos os tipos de usuários (dos avançados aos leigos) e deve ser preservada.

Sistemas (Aplicações) Distribuídos 

Transparência

  • O principal objetivo de um SD é acessar recursos ao longo do sistema, como se fossem locais (um único sistema).
  • Essa característica tornou os SD acessíveis a todos os tipos de usuários (dos avançados aos leigos) e deve ser preservada.

Sistemas (Aplicações) Distribuídos 

Microserviços

  • Monolito é um sistema não distribuído. E é feito como uma única unidade, e todos os componentes da aplicação estão juntos no mesmo lugar. Ou seja, todo o conjunto de funcionalidades disponíveis na aplicação estão representados por uma única unidade lógica executável.
  • Essa é a maneira mais natural, mais simples, mais prática e mais rápida de construir um sistema

Sistemas (Aplicações) Distribuídos 

Microserviços

  • A arquitetura de microserviços propõe um conjunto de serviços, cada um sendo executado de maneira independente, em processos separados, se comunicando através de chamadas remotas.
  • Sendo independentes, cada serviço terá o seu próprio processo de deploy e poderá escalar de acordo com suas necessidades em particular.
  • Além disso, podem ser implementados com tecnologias diferentes uns dos outros e terem o seu próprio armazenamento de dado.

Sistemas (Aplicações) Distribuídos 

Sistemas (Aplicações) Distribuídos 

Web services e API’s

  • Arquiteturas SOA (Service-oriented Architecture):
    • os serviços são conectados através de web services, por meio do protocolo mais SOAP (Simple Object Access Protocol) utilizando algum ESB (Enterprise Service Bus)
    • são consumidos por meio de um RPC (Remote Procedure Call) que consiste em representar uma chamada remota como uma chamada local de método
    • expõem funcionalidades de negócio através de operações, que fazem sentido dentro do contexto de negócio de cada serviço em específico.

Sistemas (Aplicações) Distribuídos 

REST e RPC

  • RPC encapsula uma chamada remota em uma chamada de método/função remoto representados pela abordagem SOA.

  • REST se preocupa com as operações disponíveis já estão representadas pelos verbos de requisição do protocolo HTTP.

  • Curiosidade: é muito mais comum encontrar uma API RPC-like do que REST.

Sistemas (Aplicações) Distribuídos 

Microserviços

Desafio Petshop - Parte IV

Criar as telas de -CRUD- para os objetos Cliente, Fornecedor, Endereço e Telefone.

Desafio Petshop - Parte V

Finalizar as telas de -CRUD- e relacionamentos para os objetos Cliente, Fornecedor, Endereço e Telefone.

Desafio Petshop - Parte VI

O Petshop tem produtos para ser vendidos aos clientes. Uma venda pode ter mais de um produto.
O produtos estão armazenados em um estoque, que é abastecido pelas compras feitas dos fornecedores.

Desafio Petshop - Parte VII

Agora o Petshop também oferece serviços aos seus clientes, como banho&tosa.
Esses serviços devem sem agendados previamente

UniCesumar ADS Programação III

By Henrique Vignando

Made with Slides.com

UniCesumar ADS Programação III

  • 180

More from Henrique Vignando