Edge-home-orchestration-go: [Estrutura da pasta] Siga o layout padrão do projeto Go

Criado em 31 dez. 2020  ·  7Comentários  ·  Fonte: lf-edge/edge-home-orchestration-go

Existe um layout de projeto de aplicativo Go padrão popular e muitos projetos o seguem.
Acho que devemos mudar a estrutura de pastas em termos deste guia, como a seguir.

  • GoMain/src/main > cmd
  • Buillder > build
  • samples > examples
  • samples/datastorage > configs/datastorage
  • src > internal
  • doc > docs
  • doc/edge_orchestration_api.yaml e doc/edge_orchestration_api_secure.yaml > api/...

Adicione ou retifique a lista acima, pois pode estar incorreta!

help wanted refactoring

Comentários muito úteis

Quando se trata de mnedc,

client.config deve ser alterado de acordo com o status da rede do usuário, eu acho que deveria estar nos exemplos / mnedc

Mas esta é a configuração de onde o servidor mnedc está sendo executado. Daí pensei que se fosse para a pasta de configuração seria apropriado.

Todos 7 comentários

@ t25kim 100% concorda com você. Devemos seguir o chamado padrão de fato em projetos GoLang. Além disso, é bastante simples indicar onde devemos nos referir em termos de api como você sugeriu.

Olá, Por favor, recomende se esta é a maneira correta de prosseguir com isso. (Armazenamento de dados e parte MNEDC)

Criando 2 novas pastas: "examples" e "configs" no repositório principal e usando esta árvore


--examples
----------------datastorage
----------------------sample-json-device.yaml

--configs
----------------datastorage
------------------------configuration.toml
-----------------mnedc
-------------------------client.config

Além disso, posso fazer uma das seguintes opções.

  1. Mova a pasta "nativa" em amostras para exemplos e exclua a pasta de amostras
  2. Ou deixe a pasta nativa nas amostras apenas para mover mais tarde.

Olá, Por favor, recomende se esta é a maneira correta de prosseguir com isso. (Armazenamento de dados e parte MNEDC)

Criando 2 novas pastas: "examples" e "configs" no repositório principal e usando esta árvore


--examples
----------------datastorage
----------------------sample-json-device.yaml

--configs
----------------datastorage
------------------------configuration.toml
-----------------mnedc
-------------------------client.config

@ sun-sharma Obrigado pela ideia!

Quando se trata de datastorage ,

  • parece bom para mim ir com configs/datastorage/
  • yaml arquivos configuration.toml pois os arquivos yaml devem estar alinhados com os detalhes de configuration.toml .

    • Devemos implementar configuration.toml e yaml arquivos de acordo com o cenário de borda inicial, uma vez que não são exemplos.

Quando se trata de mnedc ,

  • client.config deve ser alterado de acordo com o status da rede do usuário, acho que deve estar na faixa de examples/mnedc

Além disso, posso fazer uma das seguintes opções.

1. Move "native" folder in samples to examples and delete the samples folder

2. Or,  Leave the native folder in samples only to move later.

Eu gosto de ir com a opção 1!

Quando se trata de mnedc,

client.config deve ser alterado de acordo com o status da rede do usuário, eu acho que deveria estar nos exemplos / mnedc

Mas esta é a configuração de onde o servidor mnedc está sendo executado. Daí pensei que se fosse para a pasta de configuração seria apropriado.

Quando se trata de mnedc,

client.config deve ser alterado de acordo com o status da rede do usuário, eu acho que deveria estar nos exemplos / mnedc

Mas esta é a configuração de onde o servidor mnedc está sendo executado. Daí pensei que se fosse para a pasta de configuração seria apropriado.

Faz sentido! já que os modelos de arquivo de configuração ou configurações padrão podem estar em uma pasta de configuração .
Que tal transformar client.config em um modelo aplicado de yaml e colocá-lo como LINK ?

Fechando isso porque o problema foi resolvido.

Esta página foi útil?
0 / 5 - 0 avaliações