Prática recomendada para alterar as ações de blueprint padrão em sails.js

9

Estou procurando uma resposta para qual é a melhor prática para personalizar os blueprints CRUD sails padrão. O exemplo simples do que quero dizer é, digamos que eu preciso criar SomeModel , usando o padrão blueprint POST \someModel action e também quero obter informações sobre o usuário autenticado do req object e definir essa propriedade como req.body para use values.user.id na função beforeCreate :

module.exports = {

  attributes: {
    // some attributes
  },

  beforeCreate: function (values, cb) {
    // do something with values.user.id
  }
};

Sou muito novo no sails.js e não quero usar antipadrões, por isso estou pedindo informações sobre o que é o jeito certo de lidar com esses casos. Também seria ótimo ter alguns bons recursos sobre esse assunto.

    
por dim0_0n 21.02.2016 в 20:08
fonte

1 resposta

2

Existem algumas opções que você identificou e, como sempre, depende do seu caso de uso. Aqui estão alguns pensamentos sobre as três opções que você listou no seu comentário:

  1. Substituir controller/create - Das três, essa é a melhor opção porque não entope o código em routes ou policies para uma única instância.
  2. Escreva controller/action e adicione a config/routes.js - Embora isso funcione, ele acaba com o propósito de usar blueprints e você precisa fazer todo o código na opção 1, além de tornar seu% messenger de código routes .
  3. Aplique uma política para uma única ação create - Para fazer isso, você não precisará apenas sobrecarregar a pasta /policies , mas também o arquivo policies.js . Este é mais código E coloca a lógica para um método controlador em dois locais separados, nenhum dos quais é o controlador.

Fora destes três, a opção 1 é a melhor, porque contém o código para o seu contexto (o controlador) e minimiza o código escrito. Isso presume que você queira apenas alterar o método create para um modelo.

Nota lateral:

Como um exemplo de como seu caso de uso determina sua implementação, aqui está como defini meu aplicativo de Sails, que tem algumas rotas REST, cada uma delas respondendo de forma diferente com base no usuário que está chamando a rota (com um Facebook válido) token):

  1. Usa somente rotas de ação de blueprint (não rotas de REST de blueprint)
  2. Primeiro, passa pelas políticas: '*': ['hasFBToken', 'isTokenForMyApp', 'extractFBUser', 'extractMyAppUser'] , que armazenam fbuser , myappuser e outras variáveis em req.body
  3. Neste ponto, minha função de controlador (por exemplo, controller.action() ) é chamada e pode acessar informações sobre esse usuário e determinar se ele tem as permissões corretas para fazer o CRUD.

Profissionais deste sistema:

  • Todo o código para cada operação CRUD está contido em sua função de controlador
  • Mínimo para nenhum código em routes.js (sem código) ou policies.js (uma linha) ou /policies
  • Funciona bem com Versionamento de API (por exemplo, controllers/v1.0/controller.js ), o que é muito mais fácil de fazer com controladores com versão do que os modelos com versão. Isso significa que posso criar uma nova versão da API e, simplesmente criando um controlador em /v2.0 com uma função action() , chamadas como POST /v2.0/controller/action existirão sem roteamento extra necessário.

Espero que este exemplo ajude a ilustrar como as decisões de design foram tomadas para oferecer funcionalidade como a versão de API e consolidar o código em seu contexto específico.

    
por smileham 24.02.2016 / 23:10
fonte