Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Características de Design de Um Framework Orientado a Recurso
Postado por Dilip Krishnan , traduzido por Marcus Rehm em 17 Jun 2009
Dhananjay Nene, que também escreveu um ótimo artigo sobre a história do REST, examina várias características que são esperadas dentro da modelagem de um Framework Orientado a Recurso (Resource Oriented Framework ou ROF). O artigo também tenta capturar o relacionamento do modelo de negócio de uma aplicação e seu modelo de recurso.
De acordo com Dhananjay, algumas dessas características são evidentes devido a popularidade de alguns destes frameworks como Struts, Django, Ruby on Rails etc. No entanto, enumerando-as pode-se definir as causas do sucesso e popularidade destes frameworks. Exemplos dessas características são
Um ROF deve ter uma abstração para representar um recurso como um ponto de acesso
Se eu estivesse usando uma Ordem como um recurso e se introduzisse um método de aprovação no OrdemControlador isso não seria coerente com os requerimentos. Neste caso, deve-se modelar um recurso AprovaçãoOrdem o qual após executar, deve refletir uma troca de estado para "Aprovado" no recurso Ordem.
Dadas as considerações consistentes das Operações dos Recursos, a implementação será facilmente atingida
Um ROF deve prover suporte adicional para aspectos típicos do ciclo de vida (Ex. validação)
Os métodos do contrato (interface) do recurso devem ser implementados implicitamente pelo framework [e] o framework deve permitir o desenvolvedor "plugar" / sobrescrever com sua própria implementação [e suportar tarefas como validação].
Um ROF deve prover a possibilidade do desenvolvedor sobrescrever ou registrar métodos para tratamento dos impactos das ações PUT, POST e DELETE
Eu criei uma analogia onde um sistema baseado em REST é como um DBMS onde aplicações clientes podem fazer consultas SQL como SELECT, INSERT, UPDATE, DELETE (GET, PUT, POST, DELETE no caso HTTP/REST) nas tabelas (Recursos no caso de REST), e as regras de negócio são implementadas em "triggers" (gatilhos).
Um ROF deve prover um mecanismo para descrever ou mapear a abstração de um recurso num objeto de negócio
Existem inúmeras formas de se fazer isso. XML, YAML, DSL, Annotation - faça sua escolha. Além disso, a classe pode ser definida (no caso de uma POJO) e as características do recurso mapeadas nela, ou a classe pode manifestar estas características em tempo de execução baseada na metaprogramação em torno dos metadados. Assim o framework permitirá relacionamentos serem descritos ou inferidos.
Um ROF permitirá a representação de chaves estrangeiras através de URIs (Unified Resource Identifier) em referência de objetos de negócio
Recursos se referenciam através de URIs. Os objetos na camada de negócio referem uns aos outros utilizando referências de memória. Dadas as descrições e mapeamentos das URIs, o framework deverá permitir uma transparência ao referenciar / desreferenciar as URIs e as referências de memória.
Enquanto muitas das facetas de um ROF parecem naturais para serviços REST, algumas características necessitam de mais explicações ou análise.
Um ROF deve permitir "factory methods" para localização ou injeção de dependência de outros recursos / objetos de negócio
O desenvolvedor poderá escolher entre interagir no nível de recurso ou mais a fundo no nível de objetos de negócio. O framework deverá dar suporte necessário para estas atividades.
Um ROF deve permitir que os recursos / descrição das mídias sejam enviadas através do mesmo canal que as representações (conteúdo) dos recursos: Já que o REST permite que os tipos de mídia sejam descobertos e descritos de forma independente, o framework deve permitir que os metadados dessas mídias sejam disponibilizados para o cliente. Os metadados podem ser representados através de qualquer padrão como RDFa, XML Schema, etc.
Embora as facetas que Dhananjay cita sejam de fácil entendimento, o artigo não cobre alguns dos requisitos não funcionais tais como suporte a monitoramento, auditoria / logging, gerenciamento de transações. Leia o artigo original para mais detalhes.
Nenhum comentário
Acompanhar Discussão Responder