Registro de Boleto Online about boletonetcore HOT 13 CLOSED

@olavorn Eu vi alguns comentários no projeto do BoletoNet.

from boletonetcore.

Daria uma mechida grande, mas estava pensando e uma maneira de fazer isso de forma estruturada seria:

1. Dividir a Interface IBanco por Canais a serem implementados:
   ** Assim teríamos: IBancoCNAB240, IBancoCNAB400, IBancoOnlineWS, IBancoOnlineRest

2. Reestruturar as pastas, para facilitar a separação por canais Exemplo Bradesco:

• Banco
  |-- Bradesco
  |------ Carteiras (Carteiras conforme está hoje)
  |---------- BancoBradescoCarteira90.cs
  |------ BancoBradesco.cs (Comum)
  |------ BancoBradesco.CNAB240.cs (partial que implementaria IBancoCNAB240)
  |------ BancoBradesco.CNAB400.cs (partial que implementaria IBancoCNAB400)
  |------ BancoBradesco.OnlineWS.cs (partial que implementaria IBancoOnlineWS)
  |------ BancoBradesco.OnlineRest.cs (partial que implementaria IBancoOnlineRest)

Esse design facilitaria manutenções nos canais de forma distinta e ao mesmo tempo permitiria o compartilhamento dos elementos da classe por serem trabalhados como partial.

from boletonetcore.

Isso também nos permitiria acesso a implementações no controle de fluxo usando condicionais que hoje não temos:

(...)
if (BancoBradescoInstance is IBancoCNAB240) // se classe implementa CNAB240 ...
(...)

from boletonetcore.

Cheguei a mais ou menos isso...

    public interface IBancoCNAB400 : IBanco
    {
        string GerarDetalheRemessaCNAB400(Boleto boleto, ref int registro);
        void LerHeaderRetornoCNAB400(string registro);
        void LerDetalheRetornoCNAB400Segmento1(ref Boleto boleto, string registro);
        void LerDetalheRetornoCNAB400Segmento7(ref Boleto boleto, string registro);
        void LerTrailerRetornoCNAB400(string registro);
    }

    public interface IBancoCNAB240 : IBanco
    {
        string GerarDetalheRemessaCNAB240(Boleto boleto, ref int registro);
        void LerHeaderRetornoCNAB240(ArquivoRetorno arquivoRetorno, string registro);
        void LerDetalheRetornoCNAB240SegmentoT(ref Boleto boleto, string registro);
        void LerDetalheRetornoCNAB240SegmentoU(ref Boleto boleto, string registro);
    }

    public interface IBancoOnlineRest : IBanco
    {
        string GerarToken();
        void RegistrarBoleto(ref Boleto boleto, string registro);
        StatusBoletoOnline ConsultarStatus(ref Boleto boleto, string registro);
    }

e isso:

from boletonetcore.

@olavorn Mas qual seria o ganho para o projeto?

from boletonetcore.

Organização, Desacoplamento e Concisão:

1. Separação de formatos (cnab240 por exemplo) em arquivos específicos e além disso, separados dos arquivos de controle de fluxo (que necessitam de proteção maior) => Melhor encapsulamento
2. Novos canais (Como WebOnline WS ou REST/JSON) podem ser desenvolvidos sem impactar arquivos existentes, facilitando entedimento específico. => Extensibilidade
3. Quem necessita implementar uma nova integração não precisa implementar toda a interface IBanco atual, mas sim, uma interface especializada para o fim desejado. Ex: IBancoCNAB240 => Especialidade
4. No futuro, se quisermos plugar outras funcionalidades do CNAB, a organização atual poderá perder o sentido, pois a pasta Banco teria que se dividir com outros significados. Uma pasta para cada Banco da forma proposta, com diversas funcionalidades, é uma das soluções (não a única) que podem fazer sentido, já que está se usando partial classes e o próprio VS agrupa arquivos de classes parciais de forma inteligente. => Alternativa para expansão do escopo.
5. #14 (comment) permite que controlemos o fluxo de execução a partir das interfaces => Viabiliza pensar no caminho da Inversão de controle mais lá na frente e diminui acoplamento, que hoje é super alto.

from boletonetcore.

@olavorn É uma mudança bem grande... Praticamente reescrever todo o código!

from boletonetcore.

Olá a todos, atualmente estou migrando a parte do Zeus (projeto NFe .net) para .net core... Um dos problemas que vejo dos projetos migrados que rodam em .net framework para atualidade é a falta do uso de injeção de dependência, e até mesmo um configurador inicial fácil de ser integrado com o startup. No caso do Zeus é o mesmo projeto e a retro compatibilidade foi algo importante a ser mantido. Aqui Acredito que pelo projeto ser novo a reescrita é bem vinda.
Estou aberto para ajudar o que for possível.

from boletonetcore.

@danilobreda Toda ajuda é bem vinda! @olavorn Você poderia criar as issues, assim quem quer contribuir pode ir ajudando.

from boletonetcore.

Maravilha. @carloscds, vamos fazer um PR para uma branch nova com essa mechida grande então! Eu não me importo de fazê-la. Já fiz como teste em 3 bancos (caixa, bb e bradesco) mantendo os testes passando normal aqui. Com essa branch eu vejo muito futuro em iniciar uma abordagem com IoC mesmo, mas se formos até um pouco mais ambiciosos, poderemos implementar IoC em boa parte da estrutura interna, o que facilitará muito no futuro. @danilobreda bem vindo! Vamos tocando isso então. A primeira missão nossa seria ir migrando os bancos para a nova estrutura nesta branch. Seria seguir o modelo dos outros Bancos (BB, CEF e Bradesco).

Nesse caso, a idéia do BancoFebraban(#9) se consolida também, porque ela seria a classe básica que abrigaria o fluxo da geração, coisas que um implementador de Banco ou Carteira ou Canal não precisaria saber:

public virtual string GerarHeaderRemessa( TipoArquivo tipoArquivo, int numeroArquivoRemessa, ref int numeroRegistro)
        {
            try
            {
                var header = String.Empty;
                switch (tipoArquivo)
                {
                    case TipoArquivo.CNAB240:
                        // Cabeçalho do Arquivo
                        header += ((IBancoCNAB240)this).GerarHeaderRemessaCNAB240(ref numeroArquivoRemessa, ref numeroRegistro);
                        // Cabeçalho do Lote
                        header += Environment.NewLine;
                        header += ((IBancoCNAB240)this).GerarHeaderLoteRemessaCNAB240(ref numeroArquivoRemessa, ref numeroRegistro);
                        break;
                    case TipoArquivo.CNAB400:
                        header += ((IBancoCNAB400)this).GerarHeaderRemessaCNAB400(ref numeroArquivoRemessa, ref numeroRegistro);
                        break;
                    default:
                        throw new Exception("Tipo de arquivo inexistente.");
                }
                return header;
            }
            catch (Exception ex)
            {
                throw BoletoNetCoreException.ErroAoGerarRegistroHeaderDoArquivoRemessa(ex);
            }

        }

isso raramente muda. Mas se for necessário, basta aplicar um override na Classe Banco correspondente; Ainda não se trata de IoC, mas esse código tá quase! 🗡

Farei o PR daqui. Essa branch tá sincronizada com o BoletoNetCore/master
https://github.com/ExodusSistemas/BoletoNetCore/tree/bancofebraban

from boletonetcore.

Bancos Migrados:

• Bradesco
• Banrisul
• Banco do Brasil
• Caixa Economica
• Itau
• Santander
• Safra
• Siscoob
• Siscredi

from boletonetcore.

Para iniciar, vou fazer o trabalho "braçal" de migrar a estrutura de arquivos. 👍 a parte complicada (mas nem tanto, é trazer os métodos que estão todos nas classes que implementam IBanco para os partials e fixando nas interfaces correspondentes.

from boletonetcore.

@carloscds , tem que abrir a branch. Não consegui criar branch a partir da PR :(

Se eu fizer um pr, vc consegue criar uma TAG antes de fazer o merge? Posso fazer isso.

from boletonetcore.