[OFF] PADRÕES DE PROJETO - MVC DTO DAL BLL
Citação: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 ?
Aqui:
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 ?
O seu foco de concentração está mais nos dados (tabelas) do que no domÃnio do seu negócio. Ou seja, primeiro você pensa na estrutura do banco de dados para depois pensar nos objetos (que no seu caso, são objetos anêmicos por causa da separação de caracterÃsticas e comportamentos em classes distintas, tornando o seu projeto um hÃbrido entre POO e Procedural).
Veja isso:
www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/
Se você está usando webservices(creio eu que SOAP), então esse modelo de arquitetura não é muito indicado. Tenha em mente que todos os dados que serão [Ô]circulados[Ô] serão sempre texto(XML), que tudo está sendo controlado em termos de instância e coleta de lixo pelo IIS, que não é muito eficiente nessa parte e tem suas regras próprias que são meio que uma [Ô]caixa preta[Ô]. Então simplificar é a solução mais indicada e o uso de POO com o mÃnimo de camadas possÃvel. Se for necessário comportamentos diferentes, como para o caso de múltiplos clientes utilizando uma mesmo webservice e cada um tem suas próprias regras, então você deveria usar ou métodos complementares(métodos de extensão) ou herdar as classes básicas em classes especializadas por clientes. Você até pode seguir essa via de múltiplas camadas nesse modelo que está usando agora(já mencionado aqui o [Ô]nome popular[Ô], modelo anêmico), mas você vai estar criando uma dor de cabeça futura. Comentando o caso:
- Em se tratando de comunicação de dados via web, é SEMPRE enviar e receber o estritamente necessário. Isso é fato e não precisa de explicação mais aprofundada, por razões lógicas.
- Com esse modelo, você fica muito [Ô]amarrado[Ô] à tipos. Um [Ô]produto[Ô] por exemplo. Para um cliente pode ter apenas duas ou três propriedades, para outro, pode ter todo um encadeamento de classes filhas. Então trabalhar com toda uma classe mais complexa, quando não é necessário se torna trabalho à toa e/ou retrabalho. Porque? Simplesmente porque se você quer separar os tipos para cada cliente, você terá que criar diferentes métodos no seu webservice, cada um para seu tipo especÃfico. Criando assim, mais pontos de possÃveis exceções e manutenção. E não pense [Ô]mas é só um cliente que vai ter isso[Ô]. Já sabemos que essas coisas não são assim...
- WebService SOAP, é bem restrito quanto à tipagem. Para cada tipo [Ô]entendido[Ô] por ele, a linguagem de descrição(WSDL) precisa ser atualizada e a descrição do tipo, precisa constar nela. Isso pode criar uma confusão danada, ainda mais se o webservice será consumido por terceiros. Não é uma boa para que terceiros saibam que você possui tipos especiais para diferentes clientes/funcionalidades.
- Em cima de tudo isso, seus métodos na DAL e BLL, precisarão ser [Ô]copiados[Ô] para cada um dos tipos diferenciados e adaptados à ele, o que significa, mais manutenção, mais possÃveis pontos de exceções e trabalho/retrabalho.
- Você poderia usar um tipo genérico para tudo, mas esse teria que contemplar todos os dados de todos os tipos especÃficos, o que feriria a primeira regra(menos dados possÃveis circulando). Mas usando tipos genéricos, já não teria sentido utilizar camadas DAL e BLL, melhor reescrever tudo para POO e abusar no polimorfismo para sua classe genérica sem precisar [Ô]rebolar[Ô] com tipagem tão restrita.
Além do mais, se você está usando SOAP(que é só uma suposição, em nenhum momento você disse isso), sugiro rever essa decisão e pensar no uso de uma WebAPI REST.
- Em se tratando de comunicação de dados via web, é SEMPRE enviar e receber o estritamente necessário. Isso é fato e não precisa de explicação mais aprofundada, por razões lógicas.
- Com esse modelo, você fica muito [Ô]amarrado[Ô] à tipos. Um [Ô]produto[Ô] por exemplo. Para um cliente pode ter apenas duas ou três propriedades, para outro, pode ter todo um encadeamento de classes filhas. Então trabalhar com toda uma classe mais complexa, quando não é necessário se torna trabalho à toa e/ou retrabalho. Porque? Simplesmente porque se você quer separar os tipos para cada cliente, você terá que criar diferentes métodos no seu webservice, cada um para seu tipo especÃfico. Criando assim, mais pontos de possÃveis exceções e manutenção. E não pense [Ô]mas é só um cliente que vai ter isso[Ô]. Já sabemos que essas coisas não são assim...
- WebService SOAP, é bem restrito quanto à tipagem. Para cada tipo [Ô]entendido[Ô] por ele, a linguagem de descrição(WSDL) precisa ser atualizada e a descrição do tipo, precisa constar nela. Isso pode criar uma confusão danada, ainda mais se o webservice será consumido por terceiros. Não é uma boa para que terceiros saibam que você possui tipos especiais para diferentes clientes/funcionalidades.
- Em cima de tudo isso, seus métodos na DAL e BLL, precisarão ser [Ô]copiados[Ô] para cada um dos tipos diferenciados e adaptados à ele, o que significa, mais manutenção, mais possÃveis pontos de exceções e trabalho/retrabalho.
- Você poderia usar um tipo genérico para tudo, mas esse teria que contemplar todos os dados de todos os tipos especÃficos, o que feriria a primeira regra(menos dados possÃveis circulando). Mas usando tipos genéricos, já não teria sentido utilizar camadas DAL e BLL, melhor reescrever tudo para POO e abusar no polimorfismo para sua classe genérica sem precisar [Ô]rebolar[Ô] com tipagem tão restrita.
Além do mais, se você está usando SOAP(que é só uma suposição, em nenhum momento você disse isso), sugiro rever essa decisão e pensar no uso de uma WebAPI REST.
KERPLUNK e JABA
Estou usando RestFULL.
Na verdade eu tenho uma solução de software em indústrias, hotéis, restaurantes e alguns poucos comércios varejistas feito em C#, WebApi, e Cordova/PhoneGap para Mobile. SQL Server.
Dei umas pinceladas e algumas pequenas melhorias no projeto que roda hoje, funciona tudo tranquilo, mas como vejo que a empresa está em processo de expansão quero logo me preparar para o futuro próximo. E a minha dificuldade maior é integrar mais pessoas na equipe por falta de DOCUMENTAÇÃO e PADRÕES DE PROJETO. Pois era um projeto que somente eu codificava.
Como já adquiri um pouco mais de conhecimento nas regras de negócio, estou redesenhando do zero, com o pensamento único em objetos para lançar uma nova versão em 2018. Provavelmente vou trabalhar com 80% das Interfaces em HTML. Pois a flexibilidade é muito boa em vários aspectos.
Tenho um pouco de receio em relação a automação e esses módulos ainda vou continuar na velha janelinha do windows forms.
Em relação ao Back-End tou meio balançado, tem PHP, NodeJs e Asp.Net Core .e Java
Pelo que li o NodeJs é o bixo da goiaba, Levinho, consome menos memória por transação, mas fico com um pouco de receio em relação ao domÃnio e documentação dessa tecnologia.
O Asp.Net agora é multiplataforma, não sei essa questão do IIS pq não conheço tão a fundo, mas eu posso utilizar outro tipo de gerenciador ?
o PHP vejo o pessoal falar muito mal, que é POG isso e aquilo, mas esse realmente desconheço.
Enfim, o tópico realmente está muito bom e produtivo. vou manter aberto que vou pedir aos colegas [Ô]se possÃvel[Ô] que me deem esclarecimentos.
KERPLUNK
Esse é o motivo de está redesenhando muitas coisas, Corrigir POG é trabalho de doido meu amigo.
Estou usando RestFULL.
Citação:System.Web.Http.ApiController
Na verdade eu tenho uma solução de software em indústrias, hotéis, restaurantes e alguns poucos comércios varejistas feito em C#, WebApi, e Cordova/PhoneGap para Mobile. SQL Server.
Dei umas pinceladas e algumas pequenas melhorias no projeto que roda hoje, funciona tudo tranquilo, mas como vejo que a empresa está em processo de expansão quero logo me preparar para o futuro próximo. E a minha dificuldade maior é integrar mais pessoas na equipe por falta de DOCUMENTAÇÃO e PADRÕES DE PROJETO. Pois era um projeto que somente eu codificava.
Como já adquiri um pouco mais de conhecimento nas regras de negócio, estou redesenhando do zero, com o pensamento único em objetos para lançar uma nova versão em 2018. Provavelmente vou trabalhar com 80% das Interfaces em HTML. Pois a flexibilidade é muito boa em vários aspectos.
Tenho um pouco de receio em relação a automação e esses módulos ainda vou continuar na velha janelinha do windows forms.
Em relação ao Back-End tou meio balançado, tem PHP, NodeJs e Asp.Net Core .
Pelo que li o NodeJs é o bixo da goiaba, Levinho, consome menos memória por transação, mas fico com um pouco de receio em relação ao domÃnio e documentação dessa tecnologia.
O Asp.Net agora é multiplataforma, não sei essa questão do IIS pq não conheço tão a fundo, mas eu posso utilizar outro tipo de gerenciador ?
o PHP vejo o pessoal falar muito mal, que é POG isso e aquilo, mas esse realmente desconheço.
Enfim, o tópico realmente está muito bom e produtivo. vou manter aberto que vou pedir aos colegas [Ô]se possÃvel[Ô] que me deem esclarecimentos.
KERPLUNK
Citação:Em se tratando de comunicação de dados via web, é SEMPRE enviar e receber o estritamente necessário. Isso é fato e não precisa de explicação mais aprofundada, por razões lógicas.
- Com esse modelo, você fica muito [Ô]amarrado[Ô] à tipos. Um [Ô]produto[Ô] por exemplo. Para um cliente pode ter apenas duas ou três propriedades, para outro, pode ter todo um encadeamento de classes filhas.
Esse é o motivo de está redesenhando muitas coisas, Corrigir POG é trabalho de doido meu amigo.
Pois é, sei bem como é isso. Fazer POG é sempre comprar briga e dor de cabeça gratuita no futuro. Já passei semanas tentando corrigir coisas que se refizesse do zero, levaria algumas horas apenas e ainda assim com resultados bem aquém do esperado.
O que eu faria no seu lugar:
- Mapear as necessidades do negócio. Mapeando todas as necessidades de negócio, você consegue ver problemas que não veria se começar pelo desenho de tabelas e dados.
- Com as necessidades de dados, você pode começar um esboço de modelos de dados, dando uma idéia do que a coisa toda vai virar.
- SEMPRE preveja que o modelo de dados pode mudar, com campos e até entidades relacionadas umas à s outras, por isso, designs muito [Ô]amarrados[Ô], dependentes, vai dificultar as coisas pra você se surgir alguma necessidade nova ou não prevista.
- Use e abuse dos recursos disponibilizados pela plataforma. Polimorfismo, herança, reflection, tudo isso deve ser usado da melhor forma possÃvel. Mas não [Ô]viaje muito[Ô], sempre prefira o simples. Se uma simples herança de classes resolve, ou uma interface, então é o que você deve usar, sempre tendo em mente uma futura expansão. A máxima é: Tudo pode sempre ser expandido.
Quanto à plataforma. Eu acho NodeJS(e é minha opinião) ainda meio [Ô]virgem[Ô] para iniciar algo. Já estive vendo também o GoLang(plataforma apoiada pelo google) e essa é ainda mais [Ô]virgem[Ô], por isso, acho meio arriscado o uso delas. Já ASP.NET está totalmente consolidado, sendo usado e abusado por muita gente grande por aÃ. E se você deixar suas interfaces totalmente independentes, uma mudança na parte de server seria muito suave, com folga para testar e até mesmo mudanças parciais. PHP, sinceramente nunca gostei muito, apesar de ser largamente usado por aà e ser código aberto possibilitando até mesmo [Ô]expansões[Ô], como o que o Facebook fez, mas acho muito trabalho para uma necessidade que não está à altura, não querendo menosprezar seu negócio, mas convenhamos, um Facebook da vida, tem uma demanda [Ô]um pouquinho[Ô] maior. E sim, ASP.NET já roda multiplataforma numa boa, por isso a hospedagem se torna algo não tão problemático.
O que eu faria no seu lugar:
- Mapear as necessidades do negócio. Mapeando todas as necessidades de negócio, você consegue ver problemas que não veria se começar pelo desenho de tabelas e dados.
- Com as necessidades de dados, você pode começar um esboço de modelos de dados, dando uma idéia do que a coisa toda vai virar.
- SEMPRE preveja que o modelo de dados pode mudar, com campos e até entidades relacionadas umas à s outras, por isso, designs muito [Ô]amarrados[Ô], dependentes, vai dificultar as coisas pra você se surgir alguma necessidade nova ou não prevista.
- Use e abuse dos recursos disponibilizados pela plataforma. Polimorfismo, herança, reflection, tudo isso deve ser usado da melhor forma possÃvel. Mas não [Ô]viaje muito[Ô], sempre prefira o simples. Se uma simples herança de classes resolve, ou uma interface, então é o que você deve usar, sempre tendo em mente uma futura expansão. A máxima é: Tudo pode sempre ser expandido.
Quanto à plataforma. Eu acho NodeJS(e é minha opinião) ainda meio [Ô]virgem[Ô] para iniciar algo. Já estive vendo também o GoLang(plataforma apoiada pelo google) e essa é ainda mais [Ô]virgem[Ô], por isso, acho meio arriscado o uso delas. Já ASP.NET está totalmente consolidado, sendo usado e abusado por muita gente grande por aÃ. E se você deixar suas interfaces totalmente independentes, uma mudança na parte de server seria muito suave, com folga para testar e até mesmo mudanças parciais. PHP, sinceramente nunca gostei muito, apesar de ser largamente usado por aà e ser código aberto possibilitando até mesmo [Ô]expansões[Ô], como o que o Facebook fez, mas acho muito trabalho para uma necessidade que não está à altura, não querendo menosprezar seu negócio, mas convenhamos, um Facebook da vida, tem uma demanda [Ô]um pouquinho[Ô] maior. E sim, ASP.NET já roda multiplataforma numa boa, por isso a hospedagem se torna algo não tão problemático.
Deixa eu reformular outra pergunta relacionada ao [Ô]ShouldSerialize e DTO[Ô] que fiz lá atrás.
Caso eu precisa de uma classe que vá precisar em um único lugar do projeto só pra representar uma consulta SQL.
Eu sei que poderia usar EF para relacionar as classes, mas pelo que conversei com colegas e andei lendo, o EF é mais lento para Ler do que o próprio DataReader.
Vcs acham mais interessante eu ter a classe criada para aquele caso especifico ou enviar um tipo Anonimo pela webapi ?
Caso eu precisa de uma classe que vá precisar em um único lugar do projeto só pra representar uma consulta SQL.
Eu sei que poderia usar EF para relacionar as classes, mas pelo que conversei com colegas e andei lendo, o EF é mais lento para Ler do que o próprio DataReader.
Vcs acham mais interessante eu ter a classe criada para aquele caso especifico ou enviar um tipo Anonimo pela webapi ?
Uma regra que tomei por princÃpio: Não existe caso isolado. Tudo que você fizer vai eventualmente ser usado em vários locais.
Tópico encerrado , respostas não são mais permitidas