METODOS GENERICOS WEBAPI

 Tópico anterior Próximo tópico Novo tópico

METODOS GENERICOS WEBAPI

VB.NET

 Compartilhe  Compartilhe  Compartilhe
#495302 - 06/10/2020 10:43:42

CLEVERTON
SERRINHA
Cadast. em:Dezembro/2003


Membro da equipe

Última edição em 06/10/2020 10:45:08 por CLEVERTON

Bom dia, salve cambada!
Pode parece uma pergunta meio idiota,

Mas existe alguma forma de criar um controller genérico para eu colocar métodos comuns ?

exemplo:
[HttpGet]
List<T> ObterTodos<T>() {}

[HttpGet]
T ObterPorChavePrimaria<T>(int valuePK) {}

[HttpPost]
T Gravar<T>(T obj) {}

Ou vou ter que ficar escrevendo o mesmo método em vários controllers ?

Detalhe: eu preciso do <T> , porque para Ler os dados eu uso
context.Set<T>().FromSqlRaw('SELECT * FROM ... ')




#495305 - 06/10/2020 12:11:50

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
É um pouco trabalhoso, mas é possível sim. Usando Reflection, você pode saber o tipo e com isso chamar o método específico do tipo. No meu canal eu explico isso na série sobre reflection.

_______________________________________________________________________
Virei Orculo!
The end is nigh, be ready for the nukes!


#495308 - 06/10/2020 14:27:39

CLEVERTON
SERRINHA
Cadast. em:Dezembro/2003


Membro da equipe
Rapaz, tava olhando aqui um projetinho que fiz recente, vou testar aqui e posto o retorno, mas o que está lá é mais ou menos isso.

            [HttpGet('getlist')]
            [AllowAnonymous]
            public JsonResult GetList(string fullModelName, bool IgnorarExcluidos)
            {
                var instance =   Extension.GetInstance(fullModelName);
                var type = instance.GetType();

                Type typeCommomLocal = typeof(CommomLocal<>).MakeGenericType(type);
                var objCommomLocal = Activator.CreateInstance(typeCommomLocal);
                object[] arguments = new object[] { IgnorarExcluidos };


                MethodInfo methodInfo = objCommomLocal.GetType().GetMethod('GetListAsync', new[] { typeof(bool) });
                var obj = methodInfo.Invoke(objCommomLocal, arguments);

                return new JsonResult(obj);
            }




#495309 - 06/10/2020 14:33:14

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
Você não vai precisar do invoke e mesmo assim, não deve estar no método GET da controller. Isso deve estar nas classes de implementação de interface(ou classe abstrata). Além disso, seria bom ter suporte para operação assíncrona, o que não parece ser o caso.

_______________________________________________________________________
Virei Orculo!
The end is nigh, be ready for the nukes!


#495310 - 06/10/2020 14:35:13

CLEVERTON
SERRINHA
Cadast. em:Dezembro/2003


Membro da equipe
Vou dar um saque lá nos seus videos.



#495313 - 06/10/2020 16:48:37

CLEVERTON
SERRINHA
Cadast. em:Dezembro/2003


Membro da equipe

Última edição em 06/10/2020 16:49:04 por CLEVERTON

KERPLUNK,
eu vi seus vídeos, mas não conseguir entender muito que vc quis dizer não, vi seus videos sobre Reflection, Webapi, Odata, etc.

Ainda assim, não captei muito a sua linha de pensamento. me parece que vc está falando para Implementar os métodos que preciso dentro das minhas Models de Pessoa, Produtos, etc.

De toda a forma, o resultado ficou assim.

        public async Task<object> GetListAsync_Teste(string fullModelName)
        {
            var instance = Extension.GetInstance(fullModelName);
            var type = instance.GetType();

            Type typeCommomLocal = typeof(CommomDAL_Teste<>).MakeGenericType(type);
            var objCommomLocal = Activator.CreateInstance(typeCommomLocal, Program.configDB);
            object[] arguments = new object[] { true };

            MethodInfo methodInfo = objCommomLocal.GetType().GetMethod(nameof(ICommomDAL.SelectTodos));

            var task = Task.Run(() => methodInfo.Invoke(objCommomLocal, arguments));
            return await task.ConfigureAwait(false);
        }







Resposta escolhida #495314 - 06/10/2020 17:33:07

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
Vai funcionar e ficou assíncrono! Parabéns!
O que quis dizer é que pode abstrair um pouco mais, não é 'obrigatório', mas fica menos código espalhado saca?

_______________________________________________________________________
Virei Orculo!
The end is nigh, be ready for the nukes!


#495316 - 06/10/2020 17:50:43

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
A ideia principal de usar abstrações é justamente ter o mínimo possível de código separado. Tudo que é executado por mais de uma classe e do mesmo jeito, mudando apenas parâmetros, deveria ser abstraído. Assim, qualquer mudança vai ficar sempre tudo num lugar só e não precisa sair mudando por tudo. Lembro que usei muito isso.
Tinha feito um grid que passava só uma lista de qualquer coisa e ele fazia tudo automático:
Criava as colunas: Se o campo da coluna fosse uma referência à outro objeto, virava um botão que abria a tela de edição do objeto, em modo de leitura caso estivesse em modo de visualização no grid. Se estivesse em modo edição da linha, abria a tela de seleção do objeto, com filtros(e outro grid) retornando o selecionado. Se a coluna fosse do tipo data, no modo de edição aparecia o calendário quando entrasse na célula. Se fosse do tipo número e modo de edição, mostrava um botão de calculadora do lado(que retornava o valor).
Todas as colunas eram 'moviveis', quer dizer, poderiam ser colocadas em qualquer posição. Todas as colunas eram ocultáveis, todas as colunas dimensionáveis.

Na prática, tudo que precisava era passar para o grid a lista do que selecionei e tudo estava pronto, usando reflection e abstraindo todo o possível.

Outra que usei muito isso, foi um gerador de relatório customizável. Funcionava assim:
O usuário selecionava o tipo de relatório que queria(listagem simples, master-detail ou sumarização com gráficos).
Em seguida, selecionava a fonte de dados master, que era a origem de dados em si.
Em seguida, quais os campos que queria exibir, arrastando e soltando em uma pré-visualização. Caso o campo tivesse uma lista associada(exemplo: Cliente e suas compras), aquele campo então poderia ser usado para exibir a lista de detalhes.
Cada campo adicionável, era passível de ser ordenado, incluindo os detalhes.
Cada campo adicionado, dava a opção de ser filtrado(incluindo os de detalhe). Dependendo do tipo do campo, o filtro era modificado(data virava período, número virava um intervalo...). A tela de filtro era exibida à parte e poderia ter filtros pré-definidos que eram dinâmicos(tipo, o cara podia selecionar data_atual para algum campo de data).
Isso tudo gerava uma query que era o que fazia o relatório ser exibido de verdade.
Cabeçalho e rodapé também estava disponíveis, com somatório para qualquer campo numérico.
Tudo junto, gerava um HTML que podia ser impresso, exportado(HTML, PDF e Excel quando não fosse mater-detail).

Na prática, era só um botão que abria um YAML(que era como eu salvava a 'receita' do relatório) e era disponibilizado na aplicação. Então um objeto podia ter quantos relatórios o cliente quisesse e do jeito que ele quisesse. Ajudei a empresa que trabalhei a ganhar uma porção de clientes só com isso. E eles usam até hoje.

Enfim, abstração e reflection são ferramentas poderosas que podem deixar sua aplicação um foguete e muito versátil, além de mais simples e prática pra você.

_______________________________________________________________________
Virei Orculo!
The end is nigh, be ready for the nukes!


#495323 - 07/10/2020 09:16:51

CLEVERTON
SERRINHA
Cadast. em:Dezembro/2003


Membro da equipe
Citação:
:
Vai funcionar e ficou assíncrono! Parabéns!
O que quis dizer é que pode abstrair um pouco mais, não é 'obrigatório', mas fica menos código espalhado saca?



Valeu, vou desenrolar.
Obrigado.



 Tópico anterior Próximo tópico Novo tópico


Tópico encerrado, respostas não sao permitidas
Encerrado por CLEVERTON em 07/10/2020 09:17:36