Correto. Não é em todo projeto que devemos aplicar DDD, ele acaba sendo um overkill nos casos mais simples.
[quote=shikida]Prá mim, controle e visão são coisas que devem ficar separadas sim justamente por essa lógica de reuso. Se eu tenho uma aplicação com interface web hoje (interface web prá mim é V) e eu quero mudar para uma aplicação em flash ou uma interface em linha de comando, eu não quero ficar mexendo muito na minha camada de controle, que deve estar cheia de métodos que representam ações em cima das informações.
(…)
O exemplo clássico JAVA é o JSP na view, o Servlet no controle e os beans no modelo. JSP apresenta coisas, Servlets recebem requests e devolvem responses e alguém gerencia os beans, geralmente algum gerenciador de persistência. Se eu quiser arrancar meu JSP fora e implementar uma interface linha de comando, nada impede que os Servlets continuem pegando requests (que não precisam ser Http inclusive) e devolvendo response, desde que eles não saiam gerando HTML lá dentro. Até porque, HTML, prá mim, é decisão de VIEW.[/quote]
Os servlets que escrevemos quando usamos JSP herdam de HttpServlet, logo se você quiser mudar a visão sem mudar o controle você tem que usar HTTP sim. Eu pelo menos nunca vi uma aplicação em JSP onde os servlets não usassem HTTP.
Existe um acoplamento muito forte entre visão e controle, de maneira que quando você muda a primeira geralmente tem que mudar o segundo. Mudar a interface JSP para linha de comando aproveitando os servlets é até possível, embora seja mais complicado - seria gasto mais esforço para as adaptações do que se fosse feito da forma mais natural. Mas você consegue fazer o oposto? Mudar de linha de comando para JSP aproveitando todos os listeners que você escreveu?
Resumindo, mudar a visão implica em mudar o controle também na esmagadora maioria dos casos.
qual seria uma exceção que vc trataria na camada de modelo? Um nullpointer vá lá.
o esmiralha por exemplo, falou
minha resposta: você faria uma chamada a um método que envia um email (regra de negócio) ou reagenda um processo (regra de negócio) etc na camada de modelo?
[]
Leo K.[/quote]
Eu faria, já que o Modelo do MVC, como eu o conheço, encapsula o estado e as regras de negócio da aplicação. Qual o seu entendimento sobre o Modelo do MVC?
concordo que costuma ser mais acoplado mesmo, mas acho que é o tradeoff que o programador deve considerar.
os [responses/requests] http são conveniências criadas principalmente para passagem de parâmetro. Quanto mais conveniente, quase sempre, menos portável.
Agora, nada impede que o sujeito implemente um servlet de front controller, só despachando os requests para comandos em níveis de abstração maiores, independentes da escolha da view, usando a servlet majoritariamente para traduzir dados em strings e arrays de strings que é o que o http entende no fim das contas. Mesmo o objeto de sessão é uma escolha da camada de view, que obviamente não pode ser reaproveitado facilmente numa interface linha de comando.
mas eu acho que é justamente este meio termo entre alta coesão e baixo acoplamento que o MVC promove.
Jaba, eu entendo o modelo como entity beans. Um bando de objeto sem função de negócio que só serve para eu persistir/manipular dados.
[quote=shikida]
Jaba, eu entendo o modelo como entity beans. Um bando de objeto sem função de negócio que só serve para eu persistir/manipular dados.
[]
Leo K.[/quote]
Leo,
Respeito sua opinião, mas considere também a possibilidade de tornar seus Entity Beans objetos inteligentes que implementam regras de negócio. Entendo que a recomendação da Sun na época do EJB 2.1 era tratar Entidades como um modelo menos granular que o modelo de domínio. Mas as justificativas para essa recomendação eram baseadas exclusivamente na performance da tecnologia (que era muito ruim). Com o EJB 3 e os servidores de aplicação modernos, os Entity Beans podem integrar o próprio modelo de domínio.
Ainda segundo o livro Domain-Driven Design Quickly, a camada de apresentação é “responsável por apresentar informação ao usuário e interpretar os comandos de usuário” (tradução livre).
Inferimos, portanto, que a visão e o controle, segundo Eric Evans, pertencem à camada de apresentação, uma vez que quem exibe os dados para o usuário é a visão e quem interpreta os comandos do usuário é o controle.[/quote]
Blza, mas ficou meio confuso essa imagem, vamos ver se entendi.
User Interface - HTML (por exemplo) e Controller
Application - Service
Domain - Entidades
Infraestrutura - DAO’s,
certo?[/quote]
Considere que alguns conceitos de negócio são melhor representados como Serviços e não como Entidades. Logicamente, esses Serviços também fariam parte do Domínio.
