POSSO HERDAR A ENTIDADE PRODUTO PARA ESTOQUE?

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

POSSO HERDAR A ENTIDADE PRODUTO PARA ESTOQUE?

C#

 Compartilhe  Compartilhe  Compartilhe
#490110 - 21/08/2019 10:10:39

WELISSON
CACHOEIRO DE ITAPEMIRIM
Cadast. em:Junho/2017


Última edição em 21/08/2019 10:16:54 por WELISSON

Galera bateu uma dúvida aqui a respeito disso:

Não sou de usar herança, pois confesso que ainda não domino o POO muito bem,
então estou aprendendo aos poucos antes de fazer cagada!

Tenho duas classes BllProduto e BllEstoque:

public class BllProduto
    {
        public string CodigoEstampa;
        public int IdRegProduto;
        public string CodigoProduto;
        public string Tamanho;
        public string CodigoBarras;
        public string DescricaoProduto;
        public double PrecoCusto;
        public double PrecoVenda;
        public string CodigoFotoProduto;
        public int QtdMin;
        public int QtdMax;
}



public class BllEstoque
    {
        public int IdRegEstoque;
        public int QtdEmEstoque;
        public double ValEmEstoque;
}



Na camada DalEstoque QUERO FAZER um inner join para juntar alguns dados da tabela produtos + estoque. Eu retorno
isso em um list<BllEstoque>

public List<BllEstoque>Listar()
        {
            var sql = @"Select Estoques.IdRegEstoque, Estoques.QtdEmEstoque, Estoques.ValEmEstoque, Produtos.DescricaoProduto From Produtos INNER JOIN Estoques ON Estoques.IdRegProduto = Produtos.IdRegProduto";

            List<BllEstoque> listaEstoques = new List<BllEstoque>();

            using (DalBaseAccessConnetion db = new DalBaseAccessConnetion())
            {
                using (OleDbDataReader dr = db.ExecuteQuery(sql))
                {
                    while (dr.Read())
                    {
                        BllEstoque estoque = new BllEstoque
                        {
                            IdRegEstoque = Convert.ToInt32(dr["IdRegEstoque"]),
                            QtdEmEstoque = Convert.ToInt32(dr["QtdEmEstoque"]),
                            ValEmEstoque = Convert.ToDouble(dr["ValEmEstoque"])
                            //AQUI EU PRECISO DA PROPRIEDADES DESCRIÇÃO PRODUTO
                        };

                        listaEstoques.Add(estoque);
                    }  
                }

                return listaEstoques;
            }
        }


Porem como podem ver, eu não tenho a propriedade DescricaoProduto na classe estoque. Então a grande pergunta, como funciona
nesses casos?

1 - Crio um propriedade a mais na classe BllEstoque
2 - Crio um classe onde estoque herda estas propriedades
3 - Mudo a regra do negócio porque ta muito ruim? kk


Pois pelo que parece, usar herança agora faria total sentido pra mim, mais
vou espera pelos metres!
Vlw!




#490112 - 21/08/2019 11:00:57

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


Membro da equipe
Não encare isso como simplesmente "botar defeito", é uma crítica construtiva para ajudar a melhorar:
1 - Não use nomenclatura dessa maneira. "DescricaoProduto" e similares, não deveria existir. Você tem a propriedade "Descricao" da entidade "Produto". Semelhantemente para o modo como está usando os nomes das classes. Use NameSpaces para separar as coisas:

public class Bll.Produto
{
    public int Id { get; set; }
    public string Descricao { get; set; }
    ….por aí vai
}
(em outro arquivo)
public class Bll.Estoque
{
   public int Id { get; set; }
…..
}

Dessa maneira você não precisa usar nomes tão com prefixos/sufixos, você separa responsabilidades em namespaces apropriados

2 - A maneira como você está fazendo o design, é uma péssima idéia. Imagine um estoque como uma conta de banco: Você tem depósitos, saques, transferências, taxas e um monte de outras transações. Um estoque não é diferente. São várias movimentações feitas com um produto. Para controlar isso, você precisa de campos que descrevam a transação: Id do produto, quantidade movimentada, tipo de transação(entrada, saída, transferência...), data, lote e várias outras que você julgue necessário. O saldo é a soma das movimentações de entrada, subtraídas as saídas. Por você ter campos identificando vários aspectos da movimentação, você pode ter saldos de estoque muito mais precisos e úteis. Um exemplo:
Entrada por compra hoje de 40 quilos de tomate, do fornecedor Zezinho, no estoque da matriz, número de lote 33
Entrada por compra ontem de 10 quilos de tomate, do fornecedor Pedrinho, no estoque da matriz, número de lote 200
Saída por venda ontem de 9 quilos de tomate do estoque da matriz
Saída por venda ontem de 15 quilos de tomate do estoque da filial
Transferência hoje de 15 quilos de tomate no estoque da filial, provenientes da matriz

Agora veja bem esses registros. Com certeza, você consegue entender os dados. Com isso, consegue pensar quais campos são necessários para um registro de estoque: Tipo de movimento, quantidade, data, lote, produto, estoque/depósito e proveniência. Cada lote pode ter vínculo à documentos, como notas de compra por exemplo. Com isso, temos como determinar toda a parte de valores(por exemplo, quanto em reais, eu tenho em tomates, no estoque da matriz).

Baseados também nesses registros, temos como calcular quanto foi vendido, o quanto cada estoque(matriz e filial) tem, de quais lotes(que podemos determinar com isso a prioridade para saída, caso necessário. Tipo, tomates de lotes mais "antigos" devem ser priorizados para venda para evitar perdas, que também é uma movimentação de estoque), podemos também determinar volume de venda por loja, volume de compra por fornecedor, sasonalidade de vendas e compras, enfim, todas as coisas que clients adoram ver em relatórios. Mas dessa maneira não fica "amarrado" e esse é um dos principais objetivos da POO.

3 - Logo o que você quer fazer não faz muito sentido, pois você está "amarrando" coisas de uma maneira não muito prática e nem muito lógica. Um dos preceitos, é usar entidades onde cabíveis. Um exemplo é o Código do produto constando em uma movimentação de estoque. Você não vai ter repetidas todas as propriedades do produto na movimentação, você só tem o id. Mas você pode colocar uma propriedade "Lazy"(só lida no momento em que for acessada) do tipo "Produto" na movimentação. Assim, cada movimentação vai conter dados de produto, mas ainda é uma movimentação e caso você precise saber dados do produto, a entidade está ali.

4 - É bacana e louvável você estar interessado em melhorar seu código, admiro isso. Mas tudo isso que está fazendo de forma tão manual, já existe ferramentas que fazem de forma muito mais eficiente, prática e elegante. Se chama ORM e um dos mais conhecidos é o Entity Framework. Ele é quem se encarrega de toda essa parte de comunicar com banco, formar queries, fazer gravação e leitura e tudo mais. Você só descreve como quer seus dados, em forma de classes e todo o resto fica à cargo dele, inclusive criação de tabelas e banco de dados em si. E aqui mais uma vez entra a importância de um design de dados bem feito. Sei que está iniciando e isso parece "aff... mais uma coisa pra estudar". Bem, sim, é mais uma coisa para estudar e vai sim demorar mais um tempinho até produzir algo. Mas com o entendimento dele(do Entity Framework) e um bom design de dados, no momento que entendido, vai acelerar seu desnvolvimento exponencialmente, vai também reduzir a taxa de erros de forma muito significativa(você não vai mais ter coisas tipo "null exception", "banco não está aberto" ou qualquer outro erro primitivo desses), também terá uma framework para sua aplicação muito robusto, preparado para qualquer tipo UI e/ou API e muitas, muitas outras vantagens. Então acho bacana estudar isso, e fazer exemplos para entendimento, mas com certeza não é a melhor alternativa para uma aplicação "vendável".


_______________________________________________________________________
Virei Oráculo!
The end is nigh, be ready for the nukes!


#490113 - 21/08/2019 11:53:15

NILSONTRES
SAO PAULO
Cadast. em:Março/2012


Citação:
Não encare isso como simplesmente "botar defeito", é uma crítica construtiva para ajudar a melhorar:
1 - Não use nomenclatura dessa maneira. "DescricaoProduto" e similares, não deveria existir. Você tem a propriedade "Descricao" da entidade "Produto". Semelhantemente para o modo como está usando os nomes das classes. Use NameSpaces para separar as coisas:

public class Bll.Produto
{
    public int Id { get; set; }
    public string Descricao { get; set; }
    ….por aí vai
}
(em outro arquivo)
public class Bll.Estoque
{
   public int Id { get; set; }
…..
}

Dessa maneira você não precisa usar nomes tão com prefixos/sufixos, você separa responsabilidades em namespaces apropriados

2 - A maneira como você está fazendo o design, é uma péssima idéia. Imagine um estoque como uma conta de banco: Você tem depósitos, saques, transferências, taxas e um monte de outras transações. Um estoque não é diferente. São várias movimentações feitas com um produto. Para controlar isso, você precisa de campos que descrevam a transação: Id do produto, quantidade movimentada, tipo de transação(entrada, saída, transferência...), data, lote e várias outras que você julgue necessário. O saldo é a soma das movimentações de entrada, subtraídas as saídas. Por você ter campos identificando vários aspectos da movimentação, você pode ter saldos de estoque muito mais precisos e úteis. Um exemplo:
Entrada por compra hoje de 40 quilos de tomate, do fornecedor Zezinho, no estoque da matriz, número de lote 33
Entrada por compra ontem de 10 quilos de tomate, do fornecedor Pedrinho, no estoque da matriz, número de lote 200
Saída por venda ontem de 9 quilos de tomate do estoque da matriz
Saída por venda ontem de 15 quilos de tomate do estoque da filial
Transferência hoje de 15 quilos de tomate no estoque da filial, provenientes da matriz

Agora veja bem esses registros. Com certeza, você consegue entender os dados. Com isso, consegue pensar quais campos são necessários para um registro de estoque: Tipo de movimento, quantidade, data, lote, produto, estoque/depósito e proveniência. Cada lote pode ter vínculo à documentos, como notas de compra por exemplo. Com isso, temos como determinar toda a parte de valores(por exemplo, quanto em reais, eu tenho em tomates, no estoque da matriz).

Baseados também nesses registros, temos como calcular quanto foi vendido, o quanto cada estoque(matriz e filial) tem, de quais lotes(que podemos determinar com isso a prioridade para saída, caso necessário. Tipo, tomates de lotes mais "antigos" devem ser priorizados para venda para evitar perdas, que também é uma movimentação de estoque), podemos também determinar volume de venda por loja, volume de compra por fornecedor, sasonalidade de vendas e compras, enfim, todas as coisas que clients adoram ver em relatórios. Mas dessa maneira não fica "amarrado" e esse é um dos principais objetivos da POO.

3 - Logo o que você quer fazer não faz muito sentido, pois você está "amarrando" coisas de uma maneira não muito prática e nem muito lógica. Um dos preceitos, é usar entidades onde cabíveis. Um exemplo é o Código do produto constando em uma movimentação de estoque. Você não vai ter repetidas todas as propriedades do produto na movimentação, você só tem o id. Mas você pode colocar uma propriedade "Lazy"(só lida no momento em que for acessada) do tipo "Produto" na movimentação. Assim, cada movimentação vai conter dados de produto, mas ainda é uma movimentação e caso você precise saber dados do produto, a entidade está ali.

4 - É bacana e louvável você estar interessado em melhorar seu código, admiro isso. Mas tudo isso que está fazendo de forma tão manual, já existe ferramentas que fazem de forma muito mais eficiente, prática e elegante. Se chama ORM e um dos mais conhecidos é o Entity Framework. Ele é quem se encarrega de toda essa parte de comunicar com banco, formar queries, fazer gravação e leitura e tudo mais. Você só descreve como quer seus dados, em forma de classes e todo o resto fica à cargo dele, inclusive criação de tabelas e banco de dados em si. E aqui mais uma vez entra a importância de um design de dados bem feito. Sei que está iniciando e isso parece "aff... mais uma coisa pra estudar". Bem, sim, é mais uma coisa para estudar e vai sim demorar mais um tempinho até produzir algo. Mas com o entendimento dele(do Entity Framework) e um bom design de dados, no momento que entendido, vai acelerar seu desnvolvimento exponencialmente, vai também reduzir a taxa de erros de forma muito significativa(você não vai mais ter coisas tipo "null exception", "banco não está aberto" ou qualquer outro erro primitivo desses), também terá uma framework para sua aplicação muito robusto, preparado para qualquer tipo UI e/ou API e muitas, muitas outras vantagens. Então acho bacana estudar isso, e fazer exemplos para entendimento, mas com certeza não é a melhor alternativa para uma aplicação "vendável".  


Muito bom, parabéns pela aula.



#490114 - 21/08/2019 12:01:04

WELISSON
CACHOEIRO DE ITAPEMIRIM
Cadast. em:Junho/2017


Citação:
: KERPLUNK  


Muito obrigado por responder, é sempre bom aprender com o mais experientes. Pode ficar tranquilo, estou RILEX!

A primeira dica realmente era uma das dúvidas que tinha, foi bom saber sobre isso meu camarada :D!

Meu caso é o seguinte: Tenho uma aplicação legada no vb6 que preciso migrar para uma nova plataforma. Então estou
meio que fazendo a unha mesmo, pois não é algo tão complexo assim. E como estou aprendendo c# e ainda usando
o banco de dados do access, usar o Entity Framework acho que não é possível.

Eu tenho uma tabela para registar entras em saídas dos estoques como você sitou, meu negócio é isso:

EntradaEstoque
SaidaEstoque
Estoque
Produtos

Reforçando, eu ainda estou aprendendo c# e o .net programo nele apenas a 4 meses. Então é um novo mundo pra
mim, confesso que agora estou mais perdido!
















#490119 - 21/08/2019 13:23:55

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


Membro da equipe
Converter algo legado, quase sempre implica em modificar e até refazer o banco de dados. Não se deve construir uma casa nova sobre alicerces velhos e deprecados. Eu entendo que certamente você vai ter dados legados, mas daí entra o trabalho de construir um "conversor" para os dados.
Deixa eu tentar explicar o Entity Framework(ou simplesmente EF):
Sabe aquelas partes que você abre conexão, cria o comando, executa uma query que retorna um DataReader, percorre o DataReader trazendo os dados para as entidades e colocando as entidades em uma List<T>? Pois é, toda essa parte é automática com EF, muito bem feita, otimizada, verificada e totalmente estável. Você só se preocupa com manipular os dados. Mas pra isso funcionar, quase sempre é necessário, como já disse, refazer o banco de dados, que também é automática, você instancia a entidade e um context de dados, preenche os dados na entidade e salva a entidade no banco, não precisa sequer se preocupar se é um insert ou update, isso também é automático. Existem dezenas de tutorias excelentes por aí mostrando como usar. É bem simples na verdade e com alguma dedicação em coisa de uma semana já está dominado.

_______________________________________________________________________
Virei Oráculo!
The end is nigh, be ready for the nukes!


#490120 - 21/08/2019 13:39:10

WELISSON
CACHOEIRO DE ITAPEMIRIM
Cadast. em:Junho/2017


Citação:
:
Converter algo legado, quase sempre implica em modificar e até refazer o banco de dados. Não se deve construir uma casa nova sobre alicerces velhos e deprecados. Eu entendo que certamente você vai ter dados legados, mas daí entra o trabalho de construir um "conversor" para os dados.
Deixa eu tentar explicar o Entity Framework(ou simplesmente EF):
Sabe aquelas partes que você abre conexão, cria o comando, executa uma query que retorna um DataReader, percorre o DataReader trazendo os dados para as entidades e colocando as entidades em uma List<T>? Pois é, toda essa parte é automática com EF, muito bem feita, otimizada, verificada e totalmente estável. Você só se preocupa com manipular os dados. Mas pra isso funcionar, quase sempre é necessário, como já disse, refazer o banco de dados, que também é automática, você instancia a entidade e um context de dados, preenche os dados na entidade e salva a entidade no banco, não precisa sequer se preocupar se é um insert ou update, isso também é automático. Existem dezenas de tutorias excelentes por aí mostrando como usar. É bem simples na verdade e com alguma dedicação em coisa de uma semana já está dominado.


Cara que luxo hem, cara preciso disso urgente!

Me diz ai, qual banco de dados você usa para suas aplicações. Por exemplo, se fosse DESKTOP você iria de
sql serve?

Vou ver se consigo pegar isso nessas próximas semanas, nem que eu tenha que comprar um curso pra isso!



#490121 - 21/08/2019 13:41:18

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


Membro da equipe
Sim, geralmente uso SQL Server mesmo. E não precisa pagar nada não. Tem muitos tutoriais excelentes, a maioria dos realmente bons, estão em inglês, mas da pra entender.

_______________________________________________________________________
Virei Oráculo!
The end is nigh, be ready for the nukes!


#490131 - 21/08/2019 23:17:12

F001E
IBITINGA/SP
Cadast. em:Novembro/2004


Citação:
Pois é, toda essa parte é automática com EF, muito bem feita, otimizada, verificada e totalmente estável


Depois que vi o DAPPER estou pensando seriamente em não usar o EF. O EF processa uma caralhada de coisa e mata a performance.



#490132 - 22/08/2019 00:09:09

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


Membro da equipe
Citação:
:
Pois é, toda essa parte é automática com EF, muito bem feita, otimizada, verificada e totalmente estável

Depois que vi o DAPPER estou pensando seriamente em não usar o EF. O EF processa uma caralhada de coisa e mata a performance.

Realmente, mas ele oferece coisas que o Dapper não e que pra mim são fundamentais, uma delas é o recurso de criar migrations.

_______________________________________________________________________
Virei Oráculo!
The end is nigh, be ready for the nukes!


#490140 - 22/08/2019 10:30:33

F001E
IBITINGA/SP
Cadast. em:Novembro/2004


Citação:
Dapper não e que pra mim são fundamentais, uma delas é o recurso de criar migrations.


Isso é verdade, migrations é sensacional.



#490141 - 22/08/2019 12:55:49

WELISSON
CACHOEIRO DE ITAPEMIRIM
Cadast. em:Junho/2017


Citação:
:
Sim, geralmente uso SQL Server mesmo. E não precisa pagar nada não. Tem muitos tutoriais excelentes, a maioria dos realmente bons, estão em inglês, mas da pra entender.


Mano eu achei um conteúdo inicial sobre isso, simplesmente sensacional!

Parece até um sonho kkk,  incrível esse tal de migrations!



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


Para responder este tópico o login é requerido
Se você já possui uma conta de usuário por favor faça seu login
Se você não possui uma conta de usuário use a opção Criar usuário