Duvida de desenvolvimento com ACBRNFe

[johnbh3]

Pessoal, alguém já usou o ACBrNFe como serviço REST ou em 3 camadas?
Na visão de vocês, é melhor criar o ACBrNFe em tempo de execução (ACBrNFe := TACBrNFe.Create(nil) e depois destruí-lo no finally), atribuindo também o componente de impressão, ou deixar ele fixo (chumbado) em um DataModule não seria um problema?

Fico pensando se, em uma API, duas requisições simultâneas poderiam acabar misturando os XMLs. Ou o fato de ser uma API já isolaria isso automaticamente?

Eu poderia testar, claro, mas isso me demandaria tempo. Talvez alguém já tenha feito algo parecido ou tenha uma opinião sobre isso.

Na minha visão da o create seria melhor boa pratica, e como o horse por exemplo trabalha em modo de thread

Editado 15 Outubro, 2025 por johnbh3
ajuste

[Gilson-Prodabit-]

Bom, aqui nosso sistema é um cliente/servidor.

Colocamos o ACBrNFe no servidor, que está em um datamodule criado ao iniciar a aplicação e só é destruido ao finalizar o app. Este é responsável por todo o processo de geração/emissão das notas.

E no cliente, colocamos um componente ACBrNFE apenas quando precisamos carregar um XML, ou gerar uma inutilização. Neste caso, fazemos a criação/destruicao do componente neste modo create/finally.

Então, cada caso é um caso.

Espero ter ajudado.

Gilson S.

[valterpatrick]

Você pode criar uma API para emissão de notas onde fica em um servidor na sua empresa ou em uma VPS. 
Você pode tanto desenvolver em Delphi utilizando os componentes nativos quanto em outra linguagem utilizando o ACBrLib.

Outra solução é usar o componente nativo na sua aplicação local, isto em cada cliente seu.
Ai quando você for usar o ACBr, você instancia via código o componente ou joga ele na tela para ir utilizando.

Eu acho que há existem muitas possibilidades, talvez é entender o que é mais viavel para você e se faz sentido ter muito trabalho para desenvolver uma API ou não.

[johnbh3]

Bom dia 
Pessoal não e isso!
Eu devo ter me explicado mau!

Tudo delphi ok!
API vai ser em HORSE para enviar a NFE. A API, vai servir tanto o mobile quanto o desktop, assim evita retrabalho. O ACBrNFe não é thread-safe, o Horse roda em modo de thread, 

 

Então a duvida e técnica em relação a 

 

function emitirNFe (Abody: String;var AStatusCode: Integer): TJSONValue;
var
  NFe: TACBrNFe;
begin
  NFe := TACBrNFe.Create(nil);
  try
    NFe.Configuracoes.Arquivos.PathSalvar := '...';
    NFe.NotasFiscais.Clear;
  finally
    NFe.Free;
  end;

end;

Eu poderia criar e destruir o objeto assim.

Ou poderia colocar ele no DataModule, mas imagem exemplo 5 requisições chegando se eu chumbo o o ACBRNFE no DataMOdule, eu posso concorrer com XML de venda diferente. Destruindo o objeto conforme assim, eu tenho certeza. 

Na minha visão seria criar e destruir.
Criar/destruir o componente tem um pequeno overhead, mas irrelevante frente à segurança e estabilidade do processo.

 

Quem utiliza mais Horse vai entender bem como ele funciona em questão de thread. 

Eu posso tambem criar e desitruir o proprio dataMOdule, e deixar ele chumbado

[Juliomar Marchetti]

Eu te entendi desde o começo

é que vocês só conhecem programação se tiver form ou datamodule

não usa patterns pra lhe ajudar e criando classes interfaces etc.

então ao meu ver

faça um classe separada pois para cada chamada é uma sessão separada. não deixe nada que faça com que a sessão seja unica com um componente só

por exemplo se tu usa DataModule ele por padrão é Singleton então se tu depurar o código e catar lá no call stack vai notar

que ele será unico mesmo tu criando novos ele será um singleton e dará problemas.

então é mudar seu pensamento

[johnbh3]

function emitirNFe (Abody: String;var AStatusCode: Integer): TJSONValue;
var
  DmNFe: TDmACBr;
begin
  DmNFe := TDmACBr.Create(nil);
  try
    DmNFe.ACBrNFe.NotasFiscais.Clear;
    DmNFe.ACBrNFe.Enviar(1);
  finally
    DmNFe.Free;
  end;

end;

Ou assim, pra mim seria ainda mais confortavel 

Vamos la, 
Eu discordo um pouco mas tudo bem. Existe uma questão legada em torno de tudo que nao possibilita mudar tanto. 
Eu so discordo no seguinte ponto, e você criar manualmente com TdmNFe.Create(nil), ele NÃO será singleton.

 

Mas a duvida era deixasse chumbado, pq atualmente ele esta assim, para atender somente VCL. Mas vou precisar usar classes ja criadas que atende o produto que ja funciona e antigo.
 

Mas valeu, vou fazer uns testes de stress aqui. Pode fechar o topico !
Otimo dia a todos.

[TiagoTecchio]

Creio que o Juliomar quis dizer mais sobre a questão do alto acoplamento e a não separação de responsabilidades.

É muito comum em quem programa em Delphi a vida toda, sem muito contato com linguagens/frameworks totalmente "object oriented", como C#, Java e Dart.

Apesar de o software ser cliente/servidor eu uso essa abordagem que você comentou, criando e destruindo um DM para montar o XML da NFe/NFCe, concentrando métodos, validações, etc. É mais uma questão de conveniência, mas o ideal seria criar uma classe de montagem, abstraindo o ACBR e agrupar toda a lógica internamente.

Porém no caso de uma API, ou serviço de autorização (meu caso) não vejo com bons olhos utilizar data modules: não tem interface, seria melhor instanciar as classes "on-the-fly" e liberar imediatamente a cada requisição. Cada qual é única, não deveria se misturar com outras sessões.

Editado 16 Outubro, 2025 por TiagoTecchio

[johnbh3]

Eu entendo, mas já tenho uma questão de acoplamento forte, muito forte. De em alguns casos passar o DM por parâmetro. Então pensa, esqueça as boas práticas. Quero apenas uma alternativa que chegou em minha sprint, e coloquei isto pra equipe da forma como esta, vai haver concorrência. 

 

Pra vocês ter ideia do nivel do legado, existem casos que mudar tanto crivaram variáveis globais, porem imagina isto na API Horse não rola. Não que foi feito assim, eles usaram essas variavies no contexto e foi virando algo completo de entender 

 

Eu vu apenas minimizar muito pouco este acoplamento, e pequenos testes observei alto ganho de desempenho. E vocês assustariam em saber o tamanho da empresa, de nivel capital aberto. 

 

 

Certamente, se houvesse tempo para desacoplar tudo. Mas não diria impossível, mas totalmente inviável. 

Mas obrigado pessoal. Vou seguir um pouco do instinto dentro do que tenho. Existem funcoes tão antigas, que mecher seria um vespeiro. Vou concentar somente em n usar esta acoplamento tão forte neste DM da forma que esta. E tive problemas de mais requisições, pq não tomaram sequer cuidado de tem ACBR em instancias. E uma SPRINT até grande, justamente pq estava misturando dados de cliente aprovado com outro. 

[TiagoTecchio]

Eu te entendo, o alto acoplamento me inferniza até hoje... algumas coisas eu deixei do jeito que estão, fiz o sinal da cruz e larguei na mão de Deus.

Herança de uma época em que não me importava com padrões de projeto.

MVC e MVVM só em projetos novos.

Boa sorte!

Editado 16 Outubro, 2025 por TiagoTecchio

[Juliomar Marchetti]

9 horas atrás, johnbh3 disse:

Eu so discordo no seguinte ponto, e você criar manualmente com TdmNFe.Create(nil), ele NÃO será singleton.

 

abre o call stack e confere. 

tanto que se tu for no create do DM digita lá RemoveDatamodule(self)

[Juliomar Marchetti]

Tópico fechado por falta de retorno do usuário