2175 capítulos
  Título Autor Editora Formato Comprar item avulso Adicionar à Pasta
Medium 9788536306384

Capítulo 2 - Organizando a Lógica do Domínio

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

2

Organizando a Lógica do Domínio

D

e modo a organizar a lógica do domínio, eu a separei em três padrões principais: Roteiro de Transação (120), Modelo do Domínio (126) e Módulo Tabela

(134).

A abordagem mais simples para armazenar lógica de domínio é o Roteiro de

Transação (120). Um Roteiro de Transação (120) é, essencialmente, um procedimento que recebe os dados de entrada da camada de apresentação, efetua o processamento com validações e cálculos, armazena dados no banco de dados e invoca quaisquer operações necessárias em outros sistemas. Ele então responde com mais dados para a apresentação, talvez executando mais cálculos para ajudar a organizar e formatar a resposta. A organização fundamental é a de um único procedimento para cada ação que o usuário possa querer executar. Assim, podemos pensar neste padrão como sendo um roteiro para uma ação ou transação de negócio. Ele não tem de ser constituído, necessariamente, de um único procedimento. As partes podem ser separadas em sub-rotinas, e estas podem ser compartilhadas por diferentes Roteiros de Transação

Ver todos os capítulos
Medium 9788536306384

Capítulo 4 - Apresentação Web

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

4

Apresentação Web

U

ma das maiores mudanças nas aplicações corporativas nos últimos anos foi o surgimento das interfaces com o usuário baseadas em navegadores Web. Elas trazem muitas vantagens: nenhum software cliente para instalar, uma abordagem comum para a interface com o usuário e um acesso universal fácil. Além disso, uma série de ambientes tornam fácil criar uma aplicação Web.

A preparação de uma aplicação Web começa com o próprio software servidor.

Normalmente ele tem algum tipo de arquivo de configuração que indica quais

URLs devem ser manipuladas por quais programas. Freqüentemente, um único servidor Web pode lidar com muitos tipos de programas. Estes programas podem ser dinâmicos e podem ser acrescentados a um servidor colocando-os em um diretório apropriado. O trabalho do servidor Web é interpretar a URL de um pedido e passar o controle para um programa servidor. Há duas formas principais de estruturar um programa em um servidor Web: como um roteiro ou como uma página servidora (server page).

Ver todos os capítulos
Medium 9788536306384

Capítulo 17 - Padrões de Estado de Sessão

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

17

Padrões de Estado de Sessão

Padrões de Estado de Sessão

CAPÍTULO 17 • PADRÕES DE ESTADO DE SESSÃO

427

Estado da Sessão no Cliente (Client Session State)

Armazena o estado da sessão no cliente.

Como Funciona

Estado da Sessão no Cliente

Até mesmo os projetos mais orientados a servidor precisam de pelo menos um pequeno Estado da Sessão no Cliente, no mínimo para armazenar um identificador da sessão. Em algumas aplicações você pode considerar a colocação de todos os dados da sessão no cliente. Neste caso, o cliente envia todo o conjunto de dados de sessão em cada solicitação, e o servidor os envia de volta a cada resposta. Isso permite um servidor completamente sem estado.

Na maior parte do tempo você irá querer usar um Objeto de Transferência de Dados (380) para tratar a transferência de dados. O Objeto de Transferência de Dados (380) pode serializar a si próprio através da conexão permitindo assim que até mesmo dados complexos sejam transmitidos.

Ver todos os capítulos
Medium 9788536306384

Capítulo 8 - Juntando Tudo

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

8

Juntando Tudo

A

té agora estas narrativas olharam um aspecto de um sistema e exploraram as diversas opções para tratá-lo. Agora é hora de reunir tudo e começar a responder às questões traiçoeiras de quais padrões usar ao projetar uma aplicação corporativa.

O conselho, neste capítulo, é de muitas maneiras uma repetição do conselho dado em capítulos anteriores. Devo admitir que fiquei na dúvida se este capítulo seria necessário. Contudo, pensei que seria bom contextualizar toda a discussão agora que, espero eu, você tem pelo menos as linhas gerais do escopo completo dos padrões deste livro.

Enquanto escrevo isso, estou inteiramente ciente das limitações do meu conselho. Frodo disse em O Senhor dos Anéis: “Não peça conselhos aos Elfos, porque eles dirão não e sim.” Embora eu não esteja reivindicando qualquer conhecimento imortal, certamente entendo sua resposta de que conselhos são muitas vezes um presente perigoso. Se estiver lendo isto para tomar decisões referentes à arquitetura do seu projeto, pense que você sabe muito mais sobre seu projeto do que eu. Uma das maiores frustrações em ter bastante conhecimento sobre algo é que as pessoas muitas vezes vêm a mim em uma conferência ou enviam uma mensagem pelo correio eletrônico pedindo conselhos sobre suas decisões de processo ou arquitetura. Não há como você dar conselhos específicos baseado em uma descrição de cinco minutos. Escrevo este capítulo com ainda menos conhecimento do seu problema.

Ver todos os capítulos
Medium 9788536306384

Capítulo 9 - Padrões de Lógica de Domínio

Martin Fowler Grupo A PDF Criptografado

9

Padrões de Lógica de Domínio

Padrões de Lógica de

Domínio

CAPÍTULO

Roteiro de Transação

120

PARTE II • OS PADRÕES

Roteiro de Transação (Transaction Script)

Organiza a lógica de negócio em procedimentos onde cada procedimento lida com uma única solicitação da apresentação.

Serviço de Lançamento receitaLançada (númeroDoContrato: long, aPartirDe: Date) : Dinheiro calcularLançamentoDeReceitas (númeroDoContrato: long) : void

A maioria das aplicações podem ser percebidas como uma série de transações. Uma transação pode enxergar alguma informação organizada de alguma forma particular, outra transação pode fazer alterações nesta informação. Cada interação entre um sistema cliente e um sistema servidor contém uma certa quantidade de lógica. Em alguns casos isso pode ser tão simples quanto mostrar informações armazenadas no banco de dados. Em outros, pode envolver muitos passos de validações e cálculos.

Um Roteiro de Transação organiza toda esta lógica primariamente como um único procedimento, fazendo chamadas diretas ao banco de dados ou usando um fino envoltório para acesso ao banco de dados. Cada transação terá seu próprio Roteiro de

Ver todos os capítulos
Medium 9788536306384

Capítulo 14 - Padrões de Apresentação Web

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

14

Padrões de

Apresentação Web

Padrões de Apresentação Web

CAPÍTULO 14 • PADRÕES DE APRESENTAÇÃO WEB

315

Modelo Vista Controlador (Model View Controller)

Divide a interação da interface com o usuário em três papéis distintos.

Vista

Controlador

Modelo

O Modelo Vista Controlador (MVC) é um dos padrões mais citados (e mais citados indevidamente). Ele começou como um framework desenvolvido por Trygve Reenskaug para a plataforma Smalltalk no final dos anos 70. Desde então ele tem exercido um papel de influência na maioria dos frameworks para a interface com o usuário e no pensar sobre o projeto de interfaces com o usuário.

O MVC considera três papéis. O modelo é um objeto que representa alguma informação sobre o domínio. É um objeto não-visual contendo todos os dados e comportamento que não os usados pela interface de usuário. Na sua forma OO mais pura, o modelo é um objeto dentro de um Modelo de Domínio (126). Você também poderia pensar em um Roteiro de Transação (120) como o modelo, desde que ele não contenha nenhum mecanismo de interface com o usuário. Tal definição amplia a noção de modelo, mas se adapta à divisão de papéis do MVC.

Ver todos os capítulos
Medium 9788536306384

Capítulo 16 - Padrões de Concorrência Offline

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

16

Padrões de Concorrência Offline

Padrões de

Concorrência Offline

392

PARTE II • OS PADRÕES

Bloqueio Offline Otimista (Optimistic Offline Lock) por David Rice

Previne conflitos entre transações de negócio concorrentes detectando um conflito e desfazendo a transação.

Sessão do Martin

Banco de Dados

Sessão do David

Limite da

Transação de Sistema

lerCliente 129

retornar cliente 129 lerCliente 129 editar cliente retornar cliente 129

editar cliente

atualizar cliente 129

Bloqueio Offline

Otimista

atualizar cliente 129

desfazer

falha: versão errada do cliente

Limite da

Transação de Negócio

Muitas vezes, uma transação de negócio é executada por meio de uma série de transações de sistema. Uma vez fora de uma transação de sistema, não podemos contar apenas com nosso gerenciador de banco de dados para assegurar que a transação de negócio deixará os dados em um estado consistente. A integridade dos dados é um risco, assim que duas sessões começam a trabalhar nos mesmos registros, e atualizações perdidas são bastante possíveis. Além disso, com uma sessão editando dados que outra esteja lendo, uma leitura inconsistente torna-se provável.

Ver todos os capítulos
Medium 9788536306384

Capítulo 1 - Criando Camadas

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

1

Criando Camadas

A

criação de camadas é uma das técnicas mais comuns que os projetistas de software usam para quebrar em pedaços um sistema complexo de software.

Você encontra esta técnica em arquiteturas de máquinas, em que as camadas descendem de uma linguagem de programação com chamadas do sistema operacional aos drivers de dispositivos e conjuntos de instruções da CPU, e às portas lógicas dentro de chips. Redes de computadores têm FTP como uma camada sobre TCP, o qual, por sua vez, está sobre o IP, que está sobre a ethernet.

Ao pensar em um sistema em termos de camadas, você imagina os subsistemas principais no software dispostos de forma parecida com camadas de um bolo, em que cada camada repousa sobre uma camada mais baixa. Nesse esquema, a camada mais alta usa vários serviços definidos pela camada mais baixa, mas a camada mais baixa ignora a existência da camada mais alta. Além disso, cada camada normalmente esconde suas camadas mais baixas das camadas acima, então a camada 4 usa os serviços da camada 3, a qual usa os serviços da camada 2, mas a camada 4 ignora a existência da camada 2. (Nem todas as arquiteturas de camadas são opacas como essa, mas a maioria é.)

Ver todos os capítulos
Medium 9788536306384

Capítulo 13 - Padrões de Mapeamento em Metadados Objeto-Relacionais

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

13

Padrões de Mapeamento em Metadados ObjetoRelacionais

Padrões de Mapeamento em

Metadados Objeto-Relacionais

CAPÍTULO 13 • PADRÕES DE MAPEAMENTO EM METADADOS OBJETO-RELACIONAIS

295

Mapeamento em Metadados (Metadata Mapping)

Armazena os detalhes do mapeamento objeto-relacional em metadados.

Mapa de Dados classeDoDomínio nomeDaTabela

Mapa de Colunas

*

nomeDaColuna nomeDoCampo

Muito do código que lida com mapeamento objeto-relacional descreve como os campos no banco de dados correspondem aos campos dos objetos na memória. O código resultante tende a ser tedioso e repetitivo de escrever. Um Mapeamento em Metadados permite aos desenvolvedores definir os mapeamentos em uma forma tabular simples, a qual então pode ser processada por código genérico para realizar os detalhes de leitura, inserção e atualização dos dados.

Como Funciona

Mapeamento em Metadados

A maior decisão a ser tomada no uso do Mapeamento em Metadados é como as informações nos metadados se expressam em termos de código em execução. Há dois caminhos principais a trilhar: geração de código e programação reflexiva.

Ver todos os capítulos
Medium 9788536306384

Capítulo 15 - Padrões de Distribuição

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

15

Padrões de Distribuição

Padrões de Distribuição

368

PARTE II • OS PADRÕES

Fachada Remota (Remote Façade)

Fornece uma fachada de granularidade alta sobre objetos de granularidade baixa para melhorar a eficiência em uma rede.

Fachada Endereço

Fachada Remota

lerDadosDoEndereço gravarEndereço (rua, cidade, cep)

Endereço lerRua( ) lerCidade( ) lerCep( ) gravarRua(parâmetro) gravarCidade(parâmetro) gravarCep(parâmetro)

Em um modelo orientado a objetos, você obtém melhor desempenho com objetos pequenos que tenham métodos pequenos. Isso lhe dá muitas oportunidades de controle e substituição de comportamento e de usar nomes sugestivos que deixem uma aplicação mais fácil de ser entendida. Uma das conseqüências deste comportamento de granularidade baixa é que geralmente há bastante interação entre os objetos, e esta interação normalmente requer muitas chamadas de métodos.

Dentro de um espaço de endereçamento único, interação com granularidade baixa funciona bem, mas não ocorre quando você executa chamadas entre processos. Chamadas remotas são muito mais custosas porque há muito a ser feito: dados podem ter que ser preparados, a segurança pode precisar ser verificada, pacotes podem necessitar ser roteados por meio de switches. Se os dois processos estiverem rodando em máquinas em lados opostos do globo, a velocidade da luz pode ser um fator. A verdade brutal é que qualquer chamada interprocessos é ordem de magnitude mais custosa do que uma chamada interna ao processo – mesmo se ambos os processos estiverem na mesma máquina. Esse efeito no desempenho não pode ser ignorado, mesmo por quem acredita em otimização tardia.

Ver todos os capítulos
Medium 9788536306384

Capítulo 7 - Estratégias de Distribuição

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

7

Estratégias de Distribuição

O

s objetos têm sido usados já há um certo tempo e às vezes parece que, desde sua criação, as pessoas têm querido distribuí-los. Entretanto, a distribuição de objetos tem muito mais armadilhas do que muitas pessoas percebem

[Waldo et al.], especialmente quando elas estão sob a influência dos livretos dos vendedores. Este capítulo é sobre algumas dessas duras lições – lições que tenho visto muitos dos meus clientes aprenderem de modo difícil.

O Fascínio dos Objetos Distribuídos

Há uma apresentação recorrente que eu costumava ver duas ou três vezes por ano durante revisões de projetos. Orgulhosamente, o arquiteto de sistemas de um novo sistema OO mostra seu plano para um novo sistema de objetos distribuídos – vamos fazer de conta que é algum sistema de pedidos. Ele me mostra um projeto que se parece com a Figura 7.1, com objetos remotos separados para clientes, pedidos, produtos e entregas. Cada um deles é um componente separado que pode ser colocado em um nó de processamento separado.

Ver todos os capítulos
Medium 9788536306384

Capítulo 6 - Estado da Sessão

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

6

Estado da Sessão

Q

uando falamos sobre concorrência, levantamos a questão da diferença entre transações de sistema e transações de negócio (Capítulo 5). Além de afetar a concorrência, essa diferença afeta também a forma de armazenar os dados usados em uma transação de negócio, mas que ainda não estão prontos para serem gravados de forma definitiva (commit) no banco de dados.

As diferenças entre transações de negócio e transações de sistema sustentam muito do debate sobre sessões sem estado contra sessões com estado. Muito tem sido escrito sobre esta questão, mas o problema básico muitas vezes está disfarçado atrás das questões técnicas de sistemas servidores com e sem estado. A questão fundamental é perceber que algumas sessões são inerentemente com estado e então decidir o que fazer a respeito do estado.

O Valor de Não Possuir Estado

O que as pessoas querem dizer com um servidor sem estado? O ponto principal a respeito de objetos, é óbvio, é que eles combinam estado (dados) com comportamento. Um objeto verdadeiramente sem estado é um objeto sem atributos. Tais “animais” aparecem de tempos em tempos, mas, francamente, eles são bastante raros. Na verdade, você pode argumentar, com razão, que um objeto sem estado caracteriza um projeto ruim.

Ver todos os capítulos
Medium 9788536306384

Capítulo 3 - Mapeando para Bancos de Dados Relacionais

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

3

Mapeando para Bancos de Dados

Relacionais

O

papel da camada de fonte de dados é a comunicação com as diversas partes da infra-estrutura que uma aplicação precisa para executar sua tarefa.

Uma parte proeminente deste problema é se comunicar com o banco de dados, o que, na maioria dos sistemas criados hoje, significa um banco de dados relacional. Certamente ainda há muitos dados em formatos de armazenamento mais antigos, como arquivos ISAM e VSAM de mainframes, mas a maior parte das pessoas que está construindo sistemas hoje se preocupa em trabalhar com um banco de dados relacional.

Uma das maiores razões para o sucesso dos bancos de dados relacionais é a presença da SQL, a linguagem mais padronizada para comunicação com bancos de dados. Embora a SQL seja cheia de acréscimos aborrecidos e complicados específicos de vendedores, o núcleo da sua sintaxe é comum e bem compreendido.

Padrões de Arquitetura

O primeiro conjunto de padrões abrange os padrões de arquitetura, que direcionam o modo pelo qual a lógica de domínio se comunica com o banco de dados. A escolha que você faz aqui tem amplas conseqüências sobre o seu projeto e, desta forma, dificulta a refatoração, de modo que é uma decisão na qual você deve prestar certa atenção. É também uma escolha fortemente afetada pelo modo como você projeta sua lógica de domínio.

Ver todos os capítulos
Medium 9788536306384

Capítulo 5 - Concorrência

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

5

Concorrência

por Martin Fowler e David Rice

A

concorrência é um dos aspectos mais traiçoeiros do desenvolvimento de software. Sempre que você tiver múltiplos processos ou threads manipulando os mesmos dados, depara-se com problemas de concorrência. Pensar a respeito de concorrência já é difícil, uma vez que não é fácil enumerar os possíveis cenários que podem lhe trazer problemas. Não importa o que você faça, sempre parece haver algo que você esqueceu. Além disso, a concorrência é difícil de testar. Somos fãs de um grande número de testes automatizados atuando como base para o desenvolvimento de software, mas é difícil obter testes que nos dêem a segurança de que precisamos em relação a problemas de concorrência.

Uma das grandes ironias do desenvolvimento de aplicações corporativas é que poucos ramos do desenvolvimento de software estão usando a concorrência, e menos ainda se preocupando com ela. O motivo pelo qual desenvolvedores deste tipo de aplicação podem ter esta visão ingênua de concorrência são os gerenciadores de transação. As transações fornecem um framework que ajuda a evitar muitos dos aspectos mais traiçoeiros da concorrência em uma aplicação corporativa. Enquanto você executar toda sua manipulação de dados dentro de uma transação, nada de muito ruim irá lhe acontecer.

Ver todos os capítulos
Medium 9788536306384

Capítulo 11 - Padrões Comportamentais Objeto-Relacionais

Martin Fowler Grupo A PDF Criptografado

CAPÍTULO

11

Padrões

Comportamentais

Objeto-Relacionais

Padrões Comportamentais

Objeto-Relacionais

CAPÍTULO 11 • PADRÕES COMPORTAMENTAIS OBJETO-RELACIONAIS

187

Unidade de Trabalho (Unit of Work)

Mantém uma lista de objetos afetados por uma transação de negócio e coordena a gravação das alterações e a resolução de problemas de concorrência.

Unidade de Trabalho

Quando você está enviando dados de e para um banco de dados, é importante manter registro do que você alterou, senão esses dados não serão gravados de volta no banco de dados. De maneira similar, você tem que inserir novos objetos que criou e remover quaisquer objetos que apagou.

Você pode alterar o banco de dados a cada mudança no seu modelo de objetos, mas isso pode levar a muitas chamadas pequenas ao banco de dados, o que acaba sendo muito lento. Além disso, requer que você tenha uma transação aberta para a interação inteira, o que não é prático se você tiver uma transação que envia diversas solicitações. A situação é até pior se você precisar manter registro dos objetos que leu para que possa evitar leituras inconsistentes.

Ver todos os capítulos

Carregar mais