CONSULTA DINÂMICA COM LINQ

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

CONSULTA DINÂMICA COM LINQ

C#

 Compartilhe  Compartilhe  Compartilhe
#483728 - 07/08/2018 16:48:39

CLEVERTON
SERRINHA
Cadast. em:Dezembro/2003


Membro da equipe
Dessa forma não atende não ?

  public List<PedidoCab> obterPedidoCab(myContext _context, DateTime? dataOP, int CodOp, int CodPesE, int CodPesD, int NumNF, int NumCupom, int CodOpCaixa, int CodVendedor, int CodProd, string tpNFe, string tpMov, bool NFCanc)
        {
            bool DataValida = dataOP == null ? false : true;
            DateTime _dataInvalida = new DateTime(1899, 1, 1);
            DateTime _dataValida = dataOP == null ? _dataInvalida : dataOP.ToDateTime();

            var objRetorno = (from VC in _context.VendasCab
                              join VCO in _context.VendasCab_Operacoes on VC.CodigoOperacao equals VCO.Codigo
                              join PesD in _context.Pessoas on VC.CodPessoaDestina equals PesD.Codigo
                              join PesE in _context.Pessoas on VC.CodPessoaEmissor equals PesE.Codigo
                              join vDet in _context.VendasDet on VC.Codigo equals vDet.CodigoCab
                              join Usu in _context.Usuarios on VC.CodigoUsuario equals Usu.Codigo
                              where
                              (CodOp > 0 ? VC.CodigoOperacao.Equals(CodOp) : VC.CodigoOperacao >= 0)
                              && (DataValida ? VC.DataVenda.Equals(_dataValida) : VC.DataVenda >= _dataInvalida)
                              && (CodPesE > 0 ? VC.CodPessoaEmissor.Equals(CodPesE) : VC.CodPessoaEmissor >= 0)
                              && (CodPesD > 0 ? VC.CodPessoaDestina.Equals(CodPesD) : VC.CodPessoaDestina >= 0)
                              && (NumNF > 0 ? VC.NumeroNotaE.Equals(NumNF) : VC.NumeroNotaE >= 0)
                              && (NumCupom > 0 ? VC.NumeroCupom.Equals(NumCupom) : VC.NumeroCupom >= 0)
                              && (CodOpCaixa > 0 ? VC.CodigoUsuario.Equals(CodOpCaixa) : VC.CodigoUsuario >= 0)
                              && (CodVendedor > 0 ? VC.CodigoVendedor.Equals(CodVendedor) : VC.CodigoVendedor >= 0)
                              && (CodProd > 0 ? vDet.CodigoProduto.Equals(CodProd) : vDet.CodigoProduto >= 0)
                              && (tpNFe.Trim().Length > 0 ? VC.tipoNotaE.Equals(tpNFe) : ((VC.tipoNotaE ?? "").Length >= 0))
                              && (tpMov.Trim().Length > 0 ? VC.TipoMovimento.Equals(tpMov) : ((VC.TipoMovimento ?? "").Length >= 0))
                              && (NFCanc ? VC.Excluido == true : VC.Excluido != true)
                              group vDet by
                              new
                              {
                                  Codigo = VC.Codigo,
                                  tipoOP = VCO.Nome,
                                  dataOP = VC.Agora ?? new DateTime(1899, 1, 1),
                                  NumeroNFE = VC.NumeroNotaE,
                                  NumeroDoc = VC.NumeroCupom,
                                  Emitente = PesE.Nome,
                                  Destinatario = PesD.Nome,
                                  ValorRecebido = VC.ValorRecebido,
                                  Troco = VC.Troco,
                                  Excluido = VC.Excluido,
                                  Vendedor = Usu.Nome
                              }
                              into g
                              select new PedidoCab
                              {
                                  Codigo = g.Key.Codigo,
                                  tipoOP = g.Key.tipoOP,
                                  dataOP = g.Key.dataOP,
                                  NumeroNFE = g.Key.NumeroNFE,
                                  NumeroDoc = g.Key.NumeroDoc,
                                  Emitente = g.Key.Emitente,
                                  Destinatario = g.Key.Destinatario,
                                  Desconto = g.Sum(tx => tx.Desconto),
                                  ValorRecebido = g.Key.ValorRecebido,
                                  Troco = g.Key.Troco,
                                  Excluido = g.Key.Excluido,
                                  SubTotal = g.Sum(tx => tx.TotalItem),
                                  Vendedor = g.Key.Vendedor
                              })
                              .OrderByDescending(l => l.Codigo)
                              .ToList();

            return objRetorno;
        }




#483729 - 07/08/2018 17:30:23

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


Membro da equipe
CLEVERTON, LINQ é bacana e bem elucidativo, mas no final ele será compilado para uma expressão Lambda, por isso pode acarretar em uma pequena perda de performance. Sempre que possível use expressões Lambda, caso não tenha a manha ainda de fazer, use o LINQPad, ele ajuda não só à fazer LINQ como transforma de um para outro.

_______________________________________________________________________
Gostaria de ter seu sistema Desktop "traduzido" para uma interface web? Podemos conversar...
Virei Oráculo!
The end is nigh, be ready for the nukes!


#483730 - 07/08/2018 18:53:53

CLEVERTON
SERRINHA
Cadast. em:Dezembro/2003


Membro da equipe
Citação:
:
CLEVERTON, LINQ é bacana e bem elucidativo, mas no final ele será compilado para uma expressão Lambda, por isso pode acarretar em uma pequena perda de performance. Sempre que possível use expressões Lambda, caso não tenha a manha ainda de fazer, use o LINQPad, ele ajuda não só à fazer LINQ como transforma de um para outro.


Essa consulta sem criar índices nem consegui ver o resultado de tanta demora.
Depois que criei, ficou instantaneo, mas vou pesquisar o que vc falou.



#483731 - 07/08/2018 20:52:44

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


Membro da equipe
É que em geral, a parte "pesada" de consultas complexas assim é a montagem e verificação do produto cartesiano, por isso os índices ajudam tanto.

_______________________________________________________________________
Gostaria de ter seu sistema Desktop "traduzido" para uma interface web? Podemos conversar...
Virei Oráculo!
The end is nigh, be ready for the nukes!


#483735 - 08/08/2018 09:24:43

CARINHENA
SOROCABA
Cadast. em:Junho/2004


Última edição em 08/08/2018 09:52:19 por CARINHENA

Eu nunca gostei dessa abordagem do Linq, é extramente mais lento do que o modo normal, além de aumentar a complexidade.

Sempre achei a maneira disso funcionar, meio burra.
É uma complexidade abstrata, que degrada o desempenho em até 800% (como em vários testes por ai).

Não sei como isso pegou..


Carinhena

A melhor forma de aprender e ensinando!


#483737 - 08/08/2018 09:35:11

CLEVERTON
SERRINHA
Cadast. em:Dezembro/2003


Membro da equipe

Última edição em 08/08/2018 09:37:22 por CLEVERTON

Citação:
:
Eu nunca gostei dessa abordagem do Linq, é extramente mais lento do que o modo normal, além de aumentar a complexidade.

Sempre achei a criança e a maneira disso funcionar, meio burra.
É uma complexidade abstrata, que degrada o desempenho em até 800% (como em vários testes por ai).

Não sei como isso pegou..


Complexidade de algo é muito relativo. Poderia até me arriscar a falar que é comodismo...
muitas aplicações são bugadas PQ tem muita string pra tudo.... ai na hora de fazer uma alteração no banco o bixo pega, erros só são descobertos em produção.

E sobre a questão de performance, é muito da realidade de cada um, meus bancos não entram na casa de muitos milhões de registros... a resposta  pra mim ( criando índices ) está sendo satisfatória.




#483738 - 08/08/2018 10:08:20

CARINHENA
SOROCABA
Cadast. em:Junho/2004


Última edição em 08/08/2018 10:31:34 por CARINHENA

Citação:
:
:
Eu nunca gostei dessa abordagem do Linq, é extramente mais lento do que o modo normal, além de aumentar a complexidade.

Sempre achei a criança e a maneira disso funcionar, meio burra.
É uma complexidade abstrata, que degrada o desempenho em até 800% (como em vários testes por ai).

Não sei como isso pegou..

Complexidade de algo é muito relativo. Poderia até me arriscar a falar que é comodismo...
muitas aplicações são bugadas PQ tem muita string pra tudo.... ai na hora de fazer uma alteração no banco o bixo pega, erros só são descobertos em produção.

E sobre a questão de performance, é muito da realidade de cada um, meus bancos não entram na casa de muitos milhões de registros... a resposta  pra mim ( criando índices ) está sendo satisfatória.


Eu considero comodismo quando algo é muito melhor (em todos os aspectos), tem melhor desempenho como uso.
Se não é um, nem outro, não é comodismo, no caso, consideraria modismo (aliás, boa parte dos que gostam dele, gostam porque facilita o uso, e o desenvolvedor tem a falsa impressão que é só 'persistência' de dados, não precisa se preocupar em como deixar isso preparado).

Qualquer desenvolvedor que tem como meta fazer algo com bom desempenho, sabe o quanto as consultas geradas no banco na grande maioria são BEM ruins, alteram o uso de indices e ainda anulam muitas vezes, o plano de execução.

Se você pegar aplicações complexas e robustas (Que precisam de desempenho acima de tudo), você nunca vai ver empresas usando essa abordagem.
O Entity + Linq facilitam pro desenvolvedor (Se ele abrir a mente e começar a ter que aprender coisas que antes ele NÃO precisava se preocupar com conceitos de unit of work, repositórios, dbcontext, debset, Lazy Load, entre outras coisas). Fora problemas com um monte de conversões implícitas, que você não tem controle.

Um artigo muito legal sobre isso (na visão de DBA):
http://https://blogs.msdn.microsoft.com/fcatae/2017/07/11/entity-framework-broken-linq

Mas, não entra na minha cabeça usar algo que tenho que aprender um monte de coisa que não precisava antes, com um desempenho muito pior.
Quando o Stack fez o teste com o Entity + Linq, eles usaram a melhor abordagem possível.. e da deu uma diferença absurda, imagine se o desenvolvedor acabar não usando a melhor abordagem?

Citação:
muitas aplicações são bugadas PQ tem muita string pra tudo.... ai na hora de fazer uma alteração no banco o bixo pega, erros só são descobertos em produção.  

Isso é má abordagem, não se usa string para sql.
Além do que essa abordagem é primeiro pensada em COMO salvar no banco da MELHOR maneira, e não o contrário.


Mas, enfim.. não vou me estender sobre isso, porque não vai agregar nada a quem criou o tópico para sanar sua dúvida.
Bom tópico a todos!


Carinhena

A melhor forma de aprender e ensinando!


#483741 - 08/08/2018 11:41:10

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


Membro da equipe
Olha uma coisa que posso afirmar com certeza é que empresas grandes preferem SIM abordagem de desenvolvimento mais aprimoradas. A Dell por exemplo, são raríssimos projetos onde não se usa algum tipo de ORM, quando acontece, ou é algum subset(versão própria do ORM) ou é algo muito pequeno(como algum robô) que não justificaria a implementação de algo tão complexo. Até porque, aplicações de nível alto em complexidade e escalabilidade, requerem práticas de desenvolvimento que sejam mais fáceis de serem administradas. Empresas grandes(como a Dell), dificilmente precisam se preocupar com limitações de hardware. Já vi casos de projetos bem pequenos que recebem um cluster monstruoso só pra ele e então essa preocupação é totalmente eliminada. Além disso, essas aplicações devem ser passíveis de containerização(Docker, PCF ou semelhante) e de preferência(quase que obrigatório, na realidade) multi-plataforma. O design de código é muito bem pensado, assim como o design de dados e como os dois são vinculados. A tendência é uma migração para um modelo de aplicações baseada em micro-serviços. Onde existem dezenas(às vezes milhares) de pequenos serviços que se intercomunicam, geralmente por Queue. Esse approach resulta em uma altíssima interoperabilidade. Para quem não conhece bem isso, é difícil entender como, mas vamos à um exemplo:

O cenário:
Sua aplicação possui, clientes, produtos e movimentações de produtos(venda). Ou seja, um cliente compra e isso gera um registro de movimentação de produto(basicamente um estoque).
A parte de clientes, é um micro-serviço(REST) que dispõe dados de clientes.
O mesmo caso para produtos e movimentações de produtos.
Como clientes e produtos são independentes, qualquer aplicação pode inserir/consultar/excluir clientes e produtos à vontade, em um serviço bem simples que é dedicado exclusivamente para cada uma de suas entidades respectivas.
O mesmo para movimentação de produto. Qualquer aplicação pode lançar uma movimentação de produto, consultando um produto e um cliente válido em seus respectivos serviços.
Até aqui, tudo isso pode ser conseguido com um serviço REST simples, um monolito que contenha tanto produtos quando clientes. Mas aqui entra o pulo do gato:

A empresa possui parcceiros que fazem a parte de transporte do produto até o cliente. Esses parceiros devem ser avisados que um produto foi vendido para determinado cliente para agendar a entrega. Esse aviso, não pode depender de o parceiro de transporte ficar consultando toda hora, ele deve receber algum aviso disso de forma automática. É simples, basta criar uma Queue para o serviço que contempla tanto clientes quanto produtos. Bem, esse approach não é uma boa idéia, pois um parceiro poderia ver dados que não são dele(consultar algum cliente ou produto). Obviamente que poderíamos criar todo um esquema de permissões onde o parceiro só vai ver determinados clientes ou produtos, mas isso aumentaria exponencialmente a complexidade. É aí que a separação de responsabilidade onde cada micro-serviço é responsável por apenas uma pequena parte de um processo bem maior. O parceiro, só vai ver o que interessa à ele e nada mais. Ele estará inscrito na fila e quando uma movimentação de produto é criada, uma mensagem para ele é pendurada na Queue e ele vai ver essa mensagem se estiver inscrito na Queue.

Essa coisa de boas práticas e frameworks mais robustos ou "complexos" não é para enfeite. Uma aplicação fazendo bom uso de um ORM por exemplo, é exponencialmente mais rápida quanto à manutenção e desenvolvimento.

_______________________________________________________________________
Gostaria de ter seu sistema Desktop "traduzido" para uma interface web? Podemos conversar...
Virei Oráculo!
The end is nigh, be ready for the nukes!


#483743 - 08/08/2018 11:49:31

CARINHENA
SOROCABA
Cadast. em:Junho/2004


Depende.
Você não vai ver aplicativo relacionado a bolsa de valores usando ORM, por exemplo.
Porque nesse caso, eles precisam de velocidade, coisa que o ORM hoje, não da (tirando os famosos MicroORM).
Eu sei, porque participei disso.

Você percebeu o número de abordagens para validar o uso do ORM, em diferente esferas?
Essa complexidade que o ORM trouxe apenas para economizar um bom design de banco, vale a pena?

Embora o MicroServices seja uma tendencia, isso não quer dizer que vai usar para todas as formas.

Então, tenho em mente, que a complexidade que o ORM trás  ao custo de desempenho (Que deveria ser a questão número 1), não me agrada.


Carinhena

A melhor forma de aprender e ensinando!


#483746 - 08/08/2018 12:35:38

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


Membro da equipe
Bem, não sei porque alguém teria um ORM com uma aplicativo para bolsa de valores. Mexi pouco com isso então não tenho como dizer com total certeza se seria necessário, o que fiz era basicamente um homebroker. Não precisei armazenar nada no customer. A aplicação em si, consultava por streaming os dados de da BMF. Não cheguei à fazer nada além de simples consulta, talvez se tivesse que fazer a parte de compra e venda aí talvez sim, mesmo achando que não, afinal o cliente simplesmente posta a transação e a operadora que faz a parte burocrática.

_______________________________________________________________________
Gostaria de ter seu sistema Desktop "traduzido" para uma interface web? Podemos conversar...
Virei Oráculo!
The end is nigh, be ready for the nukes!


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


Tópico encerrado, respostas não sao permitidas
Encerrado por PERCIFILHO em 13/08/2018 10:51:26