none
Benefícios e malefícios do uso de Áreas RRS feed

  • Pergunta

  • Mais uma.

    Ontem troquei informações maravilhosas com o Leonardo Lourenço, aqui mesmo no fórum.

    Adiantando minhas dúvidas vi que Áreas possibilitam uma visão estratégica do negócio, pois posso separar Área para Administração, Área para Faturamento, Área para CRM e por aí vai.

    Agora a minha dúvida: Isso não cria um linguição no projeto? Faço referência do meu modelo (que é externo) para cada área criada?

    Isso é performático e prático?

    Renata

    quinta-feira, 17 de outubro de 2013 13:43

Respostas

  • Com certeza é a abordagem mais correta se você desenvolver pelo conceito de "areas".

    Usar áreas e fazer todos os contextos em uma única aplicação na minha opinião deixa os projetos muito complexos.

    Dividir para consquistar já diria Sun-Tzu :)

    • Marcado como Resposta Renata Cristina segunda-feira, 11 de novembro de 2013 13:43
    sábado, 9 de novembro de 2013 15:00
    Moderador
  • Raphael e João, valeu e muito.

    Na realidade, a solução do problema que apresentei, em teoria, é muito simples: DDD.

    Na prática entretanto, DDD é assunto para a versão 10.

    Porque coloquei desta forma?

    Considerando meu texto de abertura, Adiantando minhas dúvidas vi que Áreas possibilitam uma visão estratégica do negócio, pois posso separar Área para Administração, Área para Faturamento, Área para CRM e por aí vai.

    notei a dificuldade em modularizar o sistema através do uso de class libraries pois acaba dando referência cruzada.

    Uso de áreas é uma alternativa, mas considero que também embola muito a coisa para reutilização de uma determinada área (por exemplo faturamento, crm, etc ) em outros projetos.

    Como disse, valeu.

    Renata

    Só pra complementar o que você disse Renata, DDD (fundamental em qualquer projeto OO).

    Mas sem TDD, não da pra chegar ao DDD de forma satisfatória.

    • Marcado como Resposta Renata Cristina segunda-feira, 11 de novembro de 2013 14:22
    segunda-feira, 11 de novembro de 2013 14:11

Todas as Respostas

  • Olá,

    Com as áreas fica mais organizados, já pensou fazer um site complexo e os arquivos tudo juntos, ficaria uma bagunça. Ai cada área teria seus modelos. So vejo benefício.




    quinta-feira, 17 de outubro de 2013 15:04
    Moderador
  • Oi Welington, valeu pela resposta.

    Entendi o que disse mas esse benefício não poderia ser atingido através da simples criação de pastas (folders)?

    Porque disse isto? Na realidade, existem modelos que são utilizados em diversas áreas, como Pessoa por exemplo.

    O que eu estou embolando é na hora de usar esses modelos vou cair em referência circular, como se criasse um modelo para pessoa e outro para faturamento.

    Por favor, sendo possível, comente.

    Renata

    quinta-feira, 17 de outubro de 2013 16:03
  • Você tem muitas rotas complexas, com as áreas ficam mais fácil gerenciar elas. Se você tem um modelo que são usado em mais de uma área, não vejo problema você colocar ele na pasta model aquela fora das áreas ou algo do tipo "models compartilhadas". Alguém concorda com isso?

    quinta-feira, 17 de outubro de 2013 23:20
    Moderador
  • Concordo com sua colocação sobre modelos sim.

    Um modelo único (class library) sendo referenciado em cada área.

    Bela observação!

    sexta-feira, 18 de outubro de 2013 00:00
  • Sei que é antigo, espero que ainda esteja em discussão! :D

    Acho que o ideal nesse cenário seria "modularizar" seu projeto.

    E a comunicação dos módulos seriam dadas por meio de REST.

    abraço!

    sexta-feira, 8 de novembro de 2013 15:27
  • Eu particularmente não gosto de usar áreas.

    Prefiro fazer em projetos separados, facilita o deploy e a manutenção.

    Usando áreas pra cada bug que você encontra e corrige você tem que republicar todo os outros contextos do sistema.


    sexta-feira, 8 de novembro de 2013 21:53
    Moderador
  • Eu particularmente não gosto de usar áreas.

    Prefiro fazer em projetos separados, facilita o deploy e a manutenção.

    Usando áreas pra cada bug que você encontra e corrige você tem que republicar todo os outros contextos do sistema.


    Concordo com você, não sei se concorda, mas a idéia que eu dei de "modularização" resolveria esse problema, e a comunicação dos módulos por meio de REST.

    sábado, 9 de novembro de 2013 01:20
  • Com certeza é a abordagem mais correta se você desenvolver pelo conceito de "areas".

    Usar áreas e fazer todos os contextos em uma única aplicação na minha opinião deixa os projetos muito complexos.

    Dividir para consquistar já diria Sun-Tzu :)

    • Marcado como Resposta Renata Cristina segunda-feira, 11 de novembro de 2013 13:43
    sábado, 9 de novembro de 2013 15:00
    Moderador
  • Raphael e João, valeu e muito.

    Na realidade, a solução do problema que apresentei, em teoria, é muito simples: DDD.

    Na prática entretanto, DDD é assunto para a versão 10.

    Porque coloquei desta forma?

    Considerando meu texto de abertura, Adiantando minhas dúvidas vi que Áreas possibilitam uma visão estratégica do negócio, pois posso separar Área para Administração, Área para Faturamento, Área para CRM e por aí vai.

    notei a dificuldade em modularizar o sistema através do uso de class libraries pois acaba dando referência cruzada.

    Uso de áreas é uma alternativa, mas considero que também embola muito a coisa para reutilização de uma determinada área (por exemplo faturamento, crm, etc ) em outros projetos.

    Como disse, valeu.

    Renata

    • Sugerido como Resposta Raphael Heitor segunda-feira, 11 de novembro de 2013 14:09
    • Não Sugerido como Resposta Raphael Heitor segunda-feira, 11 de novembro de 2013 14:09
    segunda-feira, 11 de novembro de 2013 14:03
  • Raphael e João, valeu e muito.

    Na realidade, a solução do problema que apresentei, em teoria, é muito simples: DDD.

    Na prática entretanto, DDD é assunto para a versão 10.

    Porque coloquei desta forma?

    Considerando meu texto de abertura, Adiantando minhas dúvidas vi que Áreas possibilitam uma visão estratégica do negócio, pois posso separar Área para Administração, Área para Faturamento, Área para CRM e por aí vai.

    notei a dificuldade em modularizar o sistema através do uso de class libraries pois acaba dando referência cruzada.

    Uso de áreas é uma alternativa, mas considero que também embola muito a coisa para reutilização de uma determinada área (por exemplo faturamento, crm, etc ) em outros projetos.

    Como disse, valeu.

    Renata

    Só pra complementar o que você disse Renata, DDD (fundamental em qualquer projeto OO).

    Mas sem TDD, não da pra chegar ao DDD de forma satisfatória.

    • Marcado como Resposta Renata Cristina segunda-feira, 11 de novembro de 2013 14:22
    segunda-feira, 11 de novembro de 2013 14:11