[OFF] PADRÕES DE PROJETO - MVC DTO DAL BLL
Citação:Meu projeto eu dividido por responsabilidades, mas tem coisas que acho confusas como a construção de objetos complexos, não sei se devo fazer uma camada de DTO separada para eles. Segue imagem de como está dividido meu projeto ( está faltando a WEBAPI que está em outra solução )
Bom dia GaRela!!!
Pessoal, tou aqui fazendo pequenas mudanças na versão de meu produto/aplicativo principal.
Sempre trabalhei usando os padrões DTO, DAL e BLL.
Porém a camada BLL nunca tive a compreensão adequada dela.
Perguntas:
1: A BLL deve ser feita no projeto utilizando os controllers (webservice) ?
- 1.1: alguém teria uma explicação na prática de como funciona ?
2: Se eu precisar de um objeto que envolva várias tabelas como PEDIDO que envolve (pessoas, produtos, vendas, etc), eu devo desenhar um objeto somente para este caso especifico ?
3: é adequado o uso de ShouldSerialize já que a View pode está esperando uma determinada propriedade no momento da deserialização ?
Bom, por enquanto é só isso, vi muitos e muitos artigos na NET, mas queria saber como os colegas fazem.
Citação:Sempre trabalhei usando os padrões DTO, DAL e BLL.
Esse tipo de padrão de desenvolvimento é conhecido como modelo anêmico e torna o seu projeto orientado a dados. Meu conselho é que fuja dele o mais rápido possÃvel.
blog.caelum.com.br/o-que-e-modelo-anemico-e-por-que-fugir-dele/
Citação:1: A BLL deve ser feita no projeto utilizando os controllers (webservice) ?
- 1.1: alguém teria uma explicação na prática de como funciona ?
A BLL é a camada onde você implementa toda a sua lógica de negócio. Os Controllers apenas utilizam o que já foi implementado por ela ou pela camada de dados para passar informações para a View.
Citação:2: Se eu precisar de um objeto que envolva várias tabelas como PEDIDO que envolve (pessoas, produtos, vendas, etc), eu devo desenhar um objeto somente para este caso especifico ?
Só de ver você citar tabelas para a composição da sua lógica de negócio, já é sinal de que sua orientação de desenvolvimento está sendo apenas a dados. Geralmente, o objeto Pedido já contem outros objetos dentro dele, como Cliente e Produtos. Com uma instância de Pedido você já tem tudo o que precisa, bastaria apenas populariza-los. Agora, se for necessário o uso de mais de um Pedido, é só criar uma lista deles.
Citação:3: é adequado o uso de ShouldSerialize já que a View pode está esperando uma determinada propriedade no momento da deserialização ?
Nunca precisei usar de tal recurso, então não tenho como lhe ajudar.
Citação:Esse tipo de padrão de desenvolvimento é conhecido como modelo anêmico e torna o seu projeto orientado a dados. Meu conselho é que fuja dele o mais rápido possÃvel.
Só uma duvida, aproveitando o ensejo, nesta situação seria mais recomendado mudar a estrutura para que o projeto saia da orientação de dados para ser orientado a objetos? Tanto para uma melhor identificação e manutenção como também outros fatores que envolve a troca de programador para a manutenção. Só um exemplo que já aconteceu comigo de pegar software de outros para manutenção.
Citação:Só uma duvida, aproveitando o ensejo, nesta situação seria mais recomendado mudar a estrutura para que o projeto saia da orientação de dados para ser orientado a objetos?
Esse tipo de decisão, ao meu ver, não é algo fácil de se tomar por envolver outras coisas muito importantes, como: tempo, tamanho e custo do projeto e tipos de profissionais envolvidos. Existem casos que seria melhor começar do zero mesmo devido a alta complexidade do código, dificuldade de entendimento e baixa qualidade de manutenção. Uma outra coisa muito importante também é que é mais fácil para o programador desenvolver orientado à dados, pois não precisa pensar tanto como um programador orientado à objetos. Modelar objetos de uma maneira adequada vislumbrando possuir uma facilidade na manutenção não é uma tarefa fácil, pois a dinâmica é muito maior. Por isso, ao se mudar o código para POO, pode ser mais difÃcil encontrar profissionais capacitados para seguir com tais princÃpios se o projeto for em equipe. Por outro lado, quem domina a POO está muito à frente de quem pensa orientado a dados, e para estes, recomendo fortemente a mudança. Todavia, não basta apenas mudar o paradigma em projetos reais senão possuir sua essência, pois aos poucos o projeto vai sendo convertido para o paradigma antigo novamente, e o o ganho de recompensa pode não ser tão bom como deveria.
Citação:o mais indicado para o nosso amigo é manter este projeto estável do jeito que se encontra, buscando somente ler, interpretar e manter organizado da forma que se encontra, para os próximos talvez POO seria melhor aplicado?
A resposta para essa pergunta é: Depende. O contexto é que vai dizer, pois não é uma questão somente de qualidade de projeto. O que pesa muito nessa hora é a estrutura interna da equipe, o tempo que vai se gastar para fazer toda essa mudança de paradigma, a busca de profissionais qualificados exigirá um custo maior, etc. Se fosse somente uma questão de código por código, claro que o recomendado seria desenvolver com o paradigma da POO, porém, muita coisa precisa ser considerada nessa balança.
Citação:A BLL é a camada onde você implementa toda a sua lógica de negócio. Os Controllers apenas utilizam o que já foi implementado por ela ou pela camada de dados para passar informações para a View.
Qual a lógica de ter ela ? pelo que vejo é só um repasse de uma camada de para outra camada.
Citação:Só de ver você citar tabelas para a composição da sua lógica de negócio, já é sinal de que sua orientação de desenvolvimento está sendo apenas a dados. Geralmente, o objeto Pedido já contem outros objetos dentro dele, como Cliente e Produtos. Com uma instância de Pedido você já tem tudo o que precisa, bastaria apenas populariza-los. Agora, se for necessário o uso de mais de um Pedido, é só criar uma lista deles.
não compreendi o termo lógica orientada a dados ?
Exemplo 1: Um sistema de estoque, por exemplo. Suponhamos que para um tipo de produto você use regime PEPS(FIFO) e para outro tipo de produto você use PEUS(FILO). Cada vez que uma movimentação de produto é feita, é na BLL que as ações necessárias de regime de produto é feita.
Exemplo 2: Um sistema de caixa. Suponhamos que compras acima de R$ 1000,00, gerem um e-mail/aviso para gerência. Quado uma conta com esse valor ou acima é cadastrada, a BLL deve se encarregar de enviar o e-mail/aviso.
Acho que esses exemplos já são de boa ajuda para entender a funcionalidade dessa camada.
Citação:Qual a lógica de ter ela ? pelo que vejo é só um repasse de uma camada de para outra camada.
O problema é que isso divide um objeto em dois, separando caracterÃsticas e comportamentos, e isso acaba ferindo os princÃpios da POO. Se baseando no exemplo do artigo que lhe passei, uma maneira orientada a objetos poderia ser o seguinte:
class NotaFiscal {
private int numero;
private double valor;
private string razaoSocial;
private bool estaEncerrado;
public void encerraNota() {
this.estaEncerrado = true;
}
}
O método encerraNota() agora está encapsulado dentro da classe que lhe deu a razão da existência. Agora não existe o risco de algum programador passar um valor [Ô]false[Ô] para encerrar a nota, tudo está sendo feito por baixo dos panos, de forma transparente para quem usa.
Citação:não compreendi o termo lógica orientada a dados ?
Essa é a forma como você pensa e elabora o seu projeto. Por exemplo, se você estivesse programando via RAD, você estaria programando orientado a componentes. Pelo forma com que você se comunica em relação ao seu projeto, percebe-se que sua concentração está sendo apenas em dados, não em caracterÃsticas e comportamentos de objetos, tudo por culpa do modelo anêmico.
Citação:A BLL é a camada responsável por regras de negócio. Como a explicação é meio abstrata, melhor exemplificar:
Exemplo 1: Um sistema de estoque, por exemplo. Suponhamos que para um tipo de produto você use regime PEPS(FIFO) e para outro tipo de produto você use PEUS(FILO). Cada vez que uma movimentação de produto é feita, é na BLL que as ações necessárias de regime de produto é feita.
Exemplo 2: Um sistema de caixa. Suponhamos que compras acima de R$ 1000,00, gerem um e-mail/aviso para gerência. Quado uma conta com esse valor ou acima é cadastrada, a BLL deve se encarregar de enviar o e-mail/aviso.
Acho que esses exemplos já são de boa ajuda para entender a funcionalidade dessa camada.
Blza, exemplos bem práticos,
Queria deixar uma pergunta dentro desse contexto.
Já que uso faço a troca de objetos via webservice, não poderia usar os Controllers para fazer a camada [Ô]BLL[Ô] ?
Vi uns artigos do Andre Baltieri, ele comenta muito sobre Responsabilidades.
Não poderia uma responsabilidade dos controllers fazer esses tratamentos já que eles recebem os objetos ?
Citação:O método encerraNota() agora está encapsulado dentro da classe que lhe deu a razão da existência. Agora não existe o risco de algum programador passar um valor [Ô]false[Ô] para encerrar a nota, tudo está sendo feito por baixo dos panos, de forma transparente para quem usa.
Ficou bem claro pra mim.
Citação:Essa é a forma como você pensa e elabora o seu projeto. Por exemplo, se você estivesse programando via RAD, você estaria programando orientado a componentes. Pelo forma com que você se comunica em relação ao seu projeto, percebe-se que sua concentração está sendo apenas em dados, não em caracterÃsticas e comportamentos de objetos, tudo por culpa do modelo anêmico.
Desculpe minha burrice kkkk, mas continuo sem compreender.
Pelo forma com que você se comunica em relação ao seu projeto, percebe-se que sua concentração está sendo apenas em dados,
Em que momento eu digo isso ?