Dúvida com MVC

Bem no conceito de mvc, o model, é quem trabalha diretamente com o negócio, ou seja, provavelmente a clase “Usuario” faz parte do model, o que eu estou sentindo falta é de uma parte intermediária, que justamente seria o controller. é uma parte do seu softweare que faz a comunicação entre a interface e as classes de negócio, pra deixar as classes de negócio independentes.

mOska:

Model não é a camada responsável pela persistencia dos dados ? Ou seja, não é onde vamos colocar a conexão com o banco, insert´s, delete’s, etc ?

As regras de negócio, ou seja, validação de dados digitados pelo usuário, não é o papel do Controller ?

Mas no caso da minha questão: que código colocaria no método
private void btAnteriorActionPerformed(java.awt.event.ActionEvent evt)
para que ao clicar no botão os dados apresentados na tela sejam atualizados corretamente ?

Obrigado.

Um abraço,

Olá.

Está havendo uma certa confusão de conceitos. A camada de persistência não é prevista pela arquitetura MVC. Apenas modele-a como uma quarta camada, que conhece o modelo, mas não tem conhecimento do controller ou da view.

No Model, represente o seu sistema. Os componentes. Seus problemas. A "inteligência" do seu sistema, que resolve esses problemas. No MVC clássico, esse model deve ser "observável" pela interface, que por sua vez deve ser capaz de se atualizar (http://en.wikipedia.org/wiki/Observer_pattern).

A validação dos dados pode ser papel do Controller, mas muitas vezes vai exigir colaboração do Model (exemplo: como saber se já existe um usuário cadastrado com determinado e-mail?).

Mais leitura:
http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas
http://www.akitaonrails.com/articles/2006/11/01/mvc-vs-model-2

Enfim, um pouco de prática.

Pela breve descrição do teu problema, imagino que no modelo haja duas classes. Uma classe Usuario, e uma outra, que mantém uma lista ordenada de objetos Usuario e uma referencia ao "atual" (e que tem também os metodos e a lógica para retornar proximo, ultimo, anterior, primeiro).

Na arquitetura proposta pelo swing, deverias usar subclasses de javax.swing.Action para cada ação ("proximo", "anterior" etc) e fazer uso delas na camada de apresentação ("view", a janela do programa). Segue código exemplo.

class Model extends Observable {
  private Usuario atual;
  private List<Usuario> list;
  public Usuario proximo() {}
  public Usuario anterior() {}
  public Usuario atual() {}
  ...
  public void setUsuario(Usuario u) {
    ...
    setChanged();
    notifyObservers();
  }
}

public class ProximoAction extends AbstractAction implements Action {
  private Model model;

  public ProximoAction(Model m) {...}

  public void actionPerformed(ActionEvent evt) {
    model.setUsuario(model.proximo()); //gera um evento na interface
  }
}

public class View extends JFrame {
  private Model model;

  public View (Model m) {
    this.model = m;
    model.addObserver(this); //registra-se como "observador"
  }
  ...
  public void construirJanela() {
    jButtonProximo = new JButton();
    jButtonProximo.setAction(new ProximoAction(this.model)); //instancia o controller
  }
  ...
  public void update(Observable obs, Object obj) {
     //mudou o usuario 'atual' do modelo
     //atualizar campos na tela usando dados do usuario atual
     Usuario u = this.model.atual();
  }
}

Note que este approach é bem simplista, e dificilmente seria suficiente para sistemas maiores e mais complexos. E eu nem fiz a camada de persistência.
Podem ser necessários eventos e listeners mais especializados, pode ser necessário que a própria camada de apresentação mantenha um estado (http://www.martinfowler.com/eaaDev/PresentationModel.html).

Pode-se optar por responsabilizar o controller pela atualização da camada de apresentação. Pode-se usar algum framework para fazer "binding" automático (https://binding.dev.java.net/ - https://genesis.dev.java.net/).

Mas... bom... não vou escrever um livro. Não aqui, agora. :D

[]s
Bruno

bzanchet:

Desculpe pelo abuso, mas se puder me explicar mais algumas coisas…

Eu estou no começo do começo… então nunca nem tinha ouvido falar nas interfaces Observer e Action que vc citou, então, sinceramente, não consegui entender o que esta acontecendo no seu exemplo.

Meu pedido é: da pra implementar um modelo MVC sem utilizar essas interfaces e classes que vc citou ?
Explicando melhor:
Eu criei basicamente 3 classes, sendo:
-Uma classe CadastroUsuario, que é a minha tela, com todos os JTextFields e JButtons que vou utilizar.

-Uma classe Usuario, que possui todos os atributos de um usuário e getters e setters para acessá-los.

-Uma classe UsuarioDAO que possui um método Conecta(), que cria a conexão com o Banco de Dados, um método BuscaUsuario(int userID) que faz um select no banco pelo ID do usuario e retorna um objeto Usuario.

Como a coisa esta funcionando, ou seria melhor dizer, como não esta funcionando…

Executo a classe CadastroUsuario, que no seu construtor utiliza o método BuscaUsuario da classe UsuarioDao para receber um Usuario e mostra esses dados na tela.

Pra mim parece obvio que esta errado, porque:
-eu não tenho uma lista encadeada de usuarios,
-cada vez que quero mostrar outro usuario, clicando em proximo, por exemplo, eu chamo novamente o método BuscaDados da classe UsuarioDAO, o que leva a uma nova conexão com o banco e um novo select.
-a minha classe CadastroUsuario, que é a minha View (pelo menos eu acho que seja) esta utilizando a classe UsuarioDAO, o que não deveria acontecer num modelo MVC, certo ?

Só que entre saber que esta errado e como é o certo, pra mim esta uma grande distancia… será que voce pode me ajudar ?

Só mais uma questão… eu devo criar uma outra classe que irá utilizar a classe UsuarioDAO e criar uma lista de usuarios que será devolvida para a CadastroUsuario ?

Muito obrigado pela paciencia.

Um abraço.

Sim, é possível fazer uma aplicação MVC sem usar interface alguma. São só objetos, afinal.

Desculpa, mas infelizmente acho que as demais dúvidas são muito pouco específicas, nada que eu consiga responder de forma objetiva.

Meu conselho é: esqueça o padrão DAO, por enquanto. Tente entender, terminar a implementação (e até modificar) o exemplo que eu escrevi (um debugger ajuda, e modificações foram sugeridas aqui). E depois, leia sobre o DAO e tente incluí-lo no exemplo.

Se não quiser o que eu disse, tudo bem. Porém, poste aqui a implementação que fizesses, e faça perguntas mais específicas. Aí, sim, poderei ajudar.

Abraço,
Bruno

Bruno:

Vou tentar reproduzir a forma como acabei implementando e se você puder analisar e apontar onde estão os erros na abordagem vou ficar muito agradecido.

Primeiro a minha Interface com o usuario, suponho que seria minha View:

package app;

import java.util.List;

public class CadastroUsuario_2 extends javax.swing.JFrame {
    private Usuario user;
    //private List <Usuario> userLista;
    private UsuarioModel userModel = new UsuarioModel();
    
    /** Creates new form CadastroUsuario */
    public CadastroUsuario_2() {
        initComponents();
        user = userModel.atual();
        MostraDados(user);
    }
    
    private void MostraDados(Usuario u) {
        txtus_usID.setText(String.valueOf(u.getUsusId()));
        txtus_usLogin.setText(u.getUsusLogin());
        txtus_usNome.setText(u.getUsusNome());
        txtus_pePerfil.setText(u.getUspePerfil());
    }

    private void btAnteriorActionPerformed(java.awt.event.ActionEvent evt) {                                           
        user = userModel.anterior();
        MostraDados(user);
    }                                          

    private void btProximoActionPerformed(java.awt.event.ActionEvent evt) {                                          
        user = userModel.proximo();
        MostraDados(user);
    }                                         

  public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new CadastroUsuario_2().setVisible(true);
            }
        });
    }
    
     
}

Agora a minha classe Usuario (não sei como classifica-la, acredito que faça parte da camada Model):

package app;

@Entity
@Table(name = "usuario")
@NamedQueries( {
        @NamedQuery(name = "Usuario.findByUsusId", query = "SELECT u FROM Usuario u WHERE u.ususId = :ususId"),
        @NamedQuery(name = "Usuario.findByUsusLogin", query = "SELECT u FROM Usuario u WHERE u.ususLogin = :ususLogin"),
        @NamedQuery(name = "Usuario.findByUsusPassoword", query = "SELECT u FROM Usuario u WHERE u.ususPassoword = :ususPassoword"),
        @NamedQuery(name = "Usuario.findByUsusNome", query = "SELECT u FROM Usuario u WHERE u.ususNome = :ususNome"),
        @NamedQuery(name = "Usuario.findByUspePerfil", query = "SELECT u FROM Usuario u WHERE u.uspePerfil = :uspePerfil")
    })
    
public class Usuario implements Serializable {

    @Id
    @Column(name = "us_usId", nullable = false)
    private Integer ususId;

    @Column(name = "us_usLogin")
    private String ususLogin;

    @Column(name = "us_usPassoword")
    private String ususPassoword;

    @Column(name = "us_usNome")
    private String ususNome;

    @Column(name = "us_pePerfil")
    private String uspePerfil;
    
    /** Creates a new instance of Usuario */
    public Usuario() {     
    }
    
    /**
     * Cria uma nova instância de Usuario com os valores especificados.
     * @param ususId o ususId do Usuario
     */
    public Usuario(Integer ususId) {       
        Usuario userTemp = UsuarioDAO.BuscarUsuario(ususId);
        this.ususId = userTemp.getUsusId();
        this.ususLogin = userTemp.getUsusLogin();
        this.ususNome = userTemp.getUsusNome();
        this.uspePerfil = userTemp.getUspePerfil();
        this.ususPassoword = userTemp.getUsusPassoword();        
    }
        
    public Integer getUsusId() {
        return this.ususId;
    }

    public void setUsusId(Integer ususId) {
        this.ususId = ususId;
    }

    public String getUsusLogin() {
        return this.ususLogin;
    }

    public void setUsusLogin(String ususLogin) {
        this.ususLogin = ususLogin;
    }

/* Todos os outros getters e setters estariam aqui

    /**
     * Retorna um valor de código hash para o objeto.  Esta implementação computa
     * um valor de código hash baseado nos campos id deste objeto.
     * @return um valor de código hash para este objeto.
     */
    @Override
    public int hashCode() {
        int hash = 0;
        hash += (this.ususId != null ? this.ususId.hashCode() : 0);
        return hash;
    }
}

Agora a classe que chamei de UsuarioModel, mas agora não sei se ela representa esta camada:

package app;

import java.util.List;
import javax.swing.JOptionPane;

public class UsuarioModel {
    private Usuario userAtual;
    private List <Usuario> listaUser = null;
    
    
    /** Creates a new instance of UsuarioModel */
    public UsuarioModel() {
        listaUser = UsuarioDAO.BuscarListaUsuario();        
        userAtual = listaUser.get(0);
    }
    
    public Usuario proximo() {    
        
        if (listaUser.indexOf(userAtual) <  listaUser.size() - 1)
            userAtual = listaUser.get(listaUser.indexOf(userAtual)+1);  
        else
            JOptionPane.showMessageDialog(null, "Ultimo");
            
        return userAtual;
    }
    
    public Usuario anterior() {    
        if (listaUser.indexOf(userAtual) >  0)
            userAtual = listaUser.get(listaUser.indexOf(userAtual)-1);        
        return userAtual;
    }
    
    public Usuario atual() {    
        return userAtual;
    }    
}

E por fim uma classe responsável pela conexão com o banco, é nessa classe que eu pretendo colocar os métodos de persistencia, insert, update e delete, alem do select que ja coloquei:

package app;

public class UsuarioDAO {
    private static Connection conn = null;
    private static Statement st;
    private static ResultSet rs;    

    /** Creates a new instance of UsuarioDAO */
    public UsuarioDAO() {
    }
    
    private static void Conecta(){
        try {
            conn = ConnectionFactory.getConnection();        
        } catch (SQLException ex) {
            ex.printStackTrace();
        }        
    }
   
    public static List <Usuario> BuscarListaUsuario() {
        Usuario userTemp; 
        List <Usuario> listaUserTemp = new ArrayList <Usuario> ();
                
        try {            
            Conecta();
            st = conn.createStatement();
            rs = st.executeQuery("Select * from Usuario");
            while (rs.next()) {     
                userTemp = new Usuario();
                userTemp.setUsusId(rs.getInt("us_usID"));
                userTemp.setUsusNome(rs.getString("us_usNome"));
                userTemp.setUsusLogin(rs.getString("us_usLogin"));
                userTemp.setUsusPassoword(rs.getString("us_usPassoword"));
                userTemp.setUspePerfil(rs.getString
                ("us_pePerfil"));                                    
                listaUserTemp.add(userTemp);
            }
        } catch (SQLException ex) {
            ex.printStackTrace();
        }
        return listaUserTemp;
    }            
}

Para tentar diminuir cortei algumas coisas, por os métodos criados pelo NB 5.5, como o initComponents(), imports e declaração de JTextFiels e JLabels, mas no meu código esta completo e aparentemente funcioando.

Bom se alguém tiver boa vontade e paciencia para analisar meus códigos e me orientar, vou ficar realmente muito grato. De coração.

Um abraço a todos.

Amigo,
Infelizmente acho que não posso lhe responder com propriedade se está correto ou não.
Também sou novato, e estou há algum tempo pesquisando sobre MVC e DAO.
Acabei chegando na mesma conclusão que você, e estou implementando (quase) da mesma maneira. Especificamente:
Camada Model
Aqui eu fiz minhas classes que são entidades com seus atributos, setters e getters.
Camada Controller
Aqui eu fiz minhas classes DAOs que vão realizar a persistencia (via JDBC), são os métodos de inserir, alterar e excluir. Além de um método que retorna um objeto de uma classe através do atributo identificador e outro que retorna um List de objetos desta classe.
Camada View
Aqui eu fiz meus formulários (com swing) que busca um List da respectiva classe no DAO e monta o JTable, JTextFields e afins.

A unica coisa é que os métodos da classe que você chama de UsuarioModel eu colocaria na camada de visão.

Só também não sei se estou certo.

Abraços

Boa noite amigo…

Como disse tambem sou novato, no entanto gostaria de questioná-lo em alguns pontos, quem sabe assim conseguimos um ajudar o outro, não ?

Sobre a camada Model:
Concordo em classe classificar a classe que definem um objeto Usuario, por exemplo no meu caso, com pertencente a essa classe, ou seja, no meu caso tenho a classe Usuario.java que define um objeto usuário, com todos seus getters e setters.
No entanto achei que nessa camada tb colocaria a classe DAO que faz acesso e persistencia no BD.

Na camada Controller no meu exemplo, eu entendi que ficaria a minha classe UserModel, que no meu caso será responsável pelas regras de negócio.

E no que parece que concordamos plenamente, que seria a camada View, estaria a minha classe CadastroUsuario, que cria a tela para interface com usuário.

Este problema de MVC realmente está começando a chegar no limite.

Primeira coisa que todos devem se lembrar é : Esqueça que existe MVC.
Segunda coisa a lembrar : MVC não é uma forma de diferenciar o sistema em camadas em em pacotes. Aliás MVC percente apenas a 1 camada e 1 pacote.

Dito isto, esqueçam , por amor de Deus que MVC existe.
O que estão querendo e separação de responsabildade.
Vcs querem uma parte do código que construa e mostre a tela.
Uma parte que responda aos eventos da tela.
Uma parte que acesse ao banco de dados e/ou faça pesquisas de dados.

A parte que constroi e controla a tela é a parte swing. Criam JFrames com controles lá dentro , num certo layout etc…
Quando estiver funcionando a tela gerará eventos. Esses eventos vão para objetos listeners. Para começar, crie uma inner classe do frame que ouve todos os eventos necessários e responde conforme. Depois, quando entender o que está acontecendo vá separando as classes cadas vez mais, até que a controladora nem saiba que existe uma tela. Isso é um estágio MUITO avançado que não é recomendo em estágio inicial.

Qual é a arquitetura melhor para uma aplicação desktop com swing ?

1. Criação de Tela: Espera-se que o programador não tenha que criar todos os botões e layouts na mão. Alcançar um mecanismo bom para isto é complicado, mas existem frameworks por ai. O que deve ser dado a esta parte são os controladores de apresentação. Ou seja, as classes que recebem e respondem a eventos e decidem o que ha a fazer.
2. Controlo de tela. Espera-se que exista um conjunto de tipos de objeto que respondem aos eventos da tela e controlam o programa. É aqui que ficam os códigos que fazem alguma coisa. Claro que, cada tipo de evento, tem o seu tipo de controle. Ao apertar um botão uma ação é iniciada. É preciso saber qual a ação e recolher parâmetros. Isto é diferente de responder a uma seleção de uma linha numa tabela ? Quando menos for, melhor será a sua abstração e melhor será o objeto de controle.
   O inverso também é verdade. Se eu quiser mostrar m texto na tela, tenho que saber qual o label onde escrever o texto, ou não ? Quando menos eu tiver que saber da tela e seus objetos, melhor.

Atingir estes niveis de abstração e facilidade de controle não é simples. Por isso, para começar comecem por entender os objetos básicos. O que é um JComponent e quais tipos tem disponíveis. Sabes quais eventos eles geram é importantissimo. O resto é experiencia. É repetir , melhorar , aprender com os erros. Ler muito, e ENTENDER o que se lê.
Depois , daqui a um tempo, verá que tem muita coisa repetitiva e tentará colocar isso em classes à parte. Ou usar um framework swing (ou awt ou outro qq). Mas isso é no futuro. Por agora faça a coisa mais simples.

E por amor de Deus não digam que isto é MVC.

Grato pela ajuda…

Sua definição exclareceu quase todas as dúvidas…

Essas posturas são realmente motivadoras.

Zeed01, o fórum é lugar público e não tem como evitar a presença de ninguém. O negócio é invocar setModeIgnore(“On”) para individuos que só fazem barulho e continuar tentando resolver seu problema na boa.

Alguns links que podem te ajudar com o seu problema:

Esse é fundamental. Nele você vai ver que Swing implementa um MVC modificado, chamado pela Sun de separable model architecture, porque junta View e Controller, mas os separa do Model.

Se você pensar em algo bem próximo do MVC para o seu aplicativo, então isto aqui vai te ajudar bastante.

Aqui no GUJ, também já discutimos sobre isso.

Mas não pare ainda não! Tem uma série de outros artigos interessantes, padrões sugeridos, pelos arquitetos do Swing, no site do JGoodies, etc. Ou seja, se quiser trabalhar com o Swing vai ter que ler bastante, entender, suar a camisa.

O que falta às vezes é um exemplo. Pelo menos até agora eu não achei nenhum.

Uma aplicação com o rótulo: “ISSO FOI DESENVOLVIDO COM MVC”

Proporcionaria uma melhor compreensão

http://www.martinfowler.com/eaaDev/uiArchs.html

Ae galerinha, aqui vai um material + do que basico so bre mvc:

http://www-usr.inf.ufsm.br/~marvin/monografia.pdf

Guto_Magalhaes:

Ae galerinha, aqui vai um material + do que basico so bre mvc:

http://www-usr.inf.ufsm.br/~marvin/monografia.pdf

Nossa, essa monografia tem uns problemas conceituais bem graves.

Lendo a monografia eu fiquei com algumas dúvidas:
A camada Model “conversa” com as outras ou só o inverso é permitido?

Quem faz a persistência afinal é a Model, ou a Controller?
A Model não é para ser o Bean da entidade?
A Controller não é por exemplo um DAO?

Até onde vi a camada model ou qualquer uma das outras não significa uma única classe e sim uma divisão de responsabilidades, para atender a essas responsabilidades podemos ter uma classe ou um conjunto de classes.

Sendo assim, o bean da entidade e a classe DAO poderiam juntas compor a camada model.

A camada controller ficaria com a validação das regras de negócio, mas ainda estou com dúvida sobre como delimitar isso…

Por exemplo: supondo que uma dessa regras seja que o nome do cliente não pode ficar em branco… onde essa validação ficaria: no método set da classe cliente que é responsavel por não permitir que um objeto Cliente seja criado com atributos inválidos ou num método de validação da classe contoler ?

Como devem ter percebido também sou novato… sendo assim peço que nos ajudem a aclarar esses conceitos…

Obrigado.

Abraços a todos.

Encontrei um artigo muito bom e de fácil entendimento:

http://www.portaljava.com/home/modules.php?name=Content&pa=showpage&pid=138

Acho que minhas dúvidas foram totalmente sanadas agora.

Bom vou dar minha humilde opiniao…

Acredito que vocês estejam se confundindo com dois padroes de arquitetura:

1. MVC

2. Três Camadas (Que vi em alguns lugares o pessoal chamando de MVC, ou um MVC midificado.)

3. MVC
   O MVC trabalha da seguinte maneira:
   O VIEW enviar uma uma ação pro Controller. O CONTROLLER atualizar o MODEL, e o VIEW é atualizado diretamente pelo MODEL. Logo ele apresenta uma estrutura TRIANGULAR. Utilizam o pattern OBSERVER.
   Ver figura: http://upload.wikimedia.org/wikipedia/commons/2/2e/ModelViewControllerDiagram.svg

4. Três Camadas
   A confusão se segue por que muitas pessoas chamam essa arquitetura também de MVC.(inclusive vi no site da sun eles falando que é um MVC modificado). Apesar de possuir os conceitos similares de MODEL, VIEW e CONTROLLER elas são organizadas em camadas.
   MODEL = Camada de Persistencia
   VIEW = Camada de Apresentação
   CONTROLLER = logicao de negócios

A PRINCIPAL DIFERENÇA é:
No modelo 3-Camdas ou (Multi Camadas) o VIEW fala apenas com o CONTROLLER. E este se comunida com o MODEL.

Essa arquitetura em 3-Camadas ficou famosa pela utilização desta principlamente em aplicações WEB.

Acredito que o que vocês queiram utilizar é a arquitetura 3-CAMADAS (ou MVC modificado… Chamem como quiser…)

Espero que possa ter ajudado!

Bem se estiver procurando mais conteúdo sobre MVC recomendo este link.
Estarei nele adicionando este tópico como referência na lista da primeira postagem. Espero ter colaborado!

Como foi muito bem falado pelo “Shoes”, Camada e MVC são diferentes, tenham isso na cabeça, e Camada tb difere entre “Tier” e “Layer”, uma coisa que acaba de vez com a confusão de camada e MVC é simples, eu posso ter MVC em apenas UMA camada, pronto, a partir disso esta claro que MVC é diferente de CAMADAS. Sugiro ler o artigo do Shoes citado neste post (fragmental) e ler novamente a reposta do Sergio Taborda.

Um problema destes conceitos é o seguinte, a maioria tem o conceito errado sobre MVC e Camadas, então como a maioria explica errado acabamos achando que a minoria que explica certo esta errada.

[]s

Obrigado usuários por participarem do tópico criado pelo Zeed01!
Parabéns pela iniciativa.

analyser:

eu posso ter MVC em apenas UMA camada

analyser:

Como foi muito bem falado pelo “Shoes”, Camada e MVC são diferentes, tenham isso na cabeça, e Camada tb difere entre “Tier” e “Layer”, uma coisa que acaba de vez com a confusão de camada e MVC é simples, eu posso ter MVC em apenas UMA camada, pronto, a partir disso esta claro que MVC é diferente de CAMADAS. Sugiro ler o artigo do Shoes citado neste post (fragmental) e ler novamente a reposta do Sergio Taborda.

Um problema destes conceitos é o seguinte, a maioria tem o conceito errado sobre MVC e Camadas, então como a maioria explica errado acabamos achando que a minoria que explica certo esta errada.

[]s

Podemos SIM, dizer que cada parte do MVC é uma camada (layer), ou traduz de outra forma agora?
Os defensores de Domain-Driven Design vão dividir em camadas partes da aplicação, como User Interface (apresentation layer), Application Layer, Domain Layer e Infrastructure layer, o que tornaria confuso o termo layer em MVC.
Por melhor argumentação que alguns venham a dar, chamar de camada não é errôneo, mas confuso devido a traduções que dão a layer e tier aqui no Brasil. E não é porque há muitos defensores do DDD que devemos deixar de lado o BluePrints, o que me leva a uma pequena regra da faculdade: leiam sempre as bibliografias.

djemacao:

analyser:

Como foi muito bem falado pelo “Shoes”, Camada e MVC são diferentes, tenham isso na cabeça, e Camada tb difere entre “Tier” e “Layer”, uma coisa que acaba de vez com a confusão de camada e MVC é simples, eu posso ter MVC em apenas UMA camada, pronto, a partir disso esta claro que MVC é diferente de CAMADAS. Sugiro ler o artigo do Shoes citado neste post (fragmental) e ler novamente a reposta do Sergio Taborda.

Um problema destes conceitos é o seguinte, a maioria tem o conceito errado sobre MVC e Camadas, então como a maioria explica errado acabamos achando que a minoria que explica certo esta errada.

[]s

Camada ou não camada? Layer ou tier? Bom, vamos aos fatos. Falando de Java? Leiam o BluePrints:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html

Podemos SIM, dizer que cada parte do MVC é uma camada (layer), ou traduz de outra forma agora?

Sim.
Em inglês os termos tier e layer são usados indistinvamente e normalmente tier se refere a algo fisico enquando layer a algo abstrato. Essa noção de que as coisas são empilhadas como camadas de bolo têm 3 niveis de prespectiva. veja o cubo arquitetural. O cubo mostra duas dimenções em que ha empilhamento. De baixo para cima vc tem camadas que conectão a aplicação com o hardware. Estes elementos são chamados plataformas (platform). A plataforma java é uma plataforma virtual (penultimo de baixo para cima).
Da esquerda para a direita temos empilhamento logico. Se rodar o cubo verá que é um empilhamento.
Os elementos deste empilhamento são chamados andares (store). A terceira dimensão não é empilhada , são pilares cada um segura a aplicação por si mesmo.

O cubo forma um nodo. Nodos são conjuntos de andares e plataformas. Normalmente são equivalentes a máquinas (com o seu hardware, OS, jvm, etc…) mas podem haver vários nodos numa máquina fisica.

As palavras tier e layer podem significar nodos ou andares dependendo do contexto.

3-layer-design = design em 3 camadas => design em 3 andares. (design é coisa do ambito logico)
3-tier-arquitectura = arquitetura em 3 nodos

multi-tier-platform = plataforma multi-camada : aqui a palavra “camada” substitui tanto nodo quando andar porque se quer dizer que a plataforma suporta ambos.

è por isso que na escola nos ensinam a avaliar e entender o contexto, porque as palavras por si mesmas podem não ter significados objetivos (unicos)

Andar (store), Plataforma (platform) e Nodo (node) são melhores palavras porque seu significado não é ambiguo. Com esta nomenclatura “camada” significa “conjunto de componentes” e é equivalente a pacotes ou pedaços da API que trabalham num certo proposito.

MVC é um padrão de desenho para 1 andar em 1 nodo. Não é uma nomenclatura para os andares , nem os nodos.

“Modelo” não é o Dominio , como alguem falou algures nos trezentos topicos sobre MVC. “Modelo” é a parte que conversa com o Dominio. “View” Não é o que o usuário vê, mas aqui que aplicação interpreta como sendo o que o usuário interage. system.out e system.in podem ser a view. Não necessariamente a view é gráfica. A interface gráfica, em si, é um andar (o “cliente”) e pode ou não usar MVC.

Aplicações modernas , sobretudo em java separam-se em 5 andares : Cliente, Apresentação, Negocio, Integração e Recursos.
Cliente = A interface gráfica (algo desktop em swing , awt ou swt ou um browser)
Apresentação = a parte que é consultada pelo (model) do cliente. Ea media a interface grafica e o negocio. É responsável pelas famosas “logicas de tela”.
Negocio = As regras de dominio propriamente ditas. entidades, serviços, etc…
Integração= contém logicas que permitem à aplicação comunicar com outras aplicações. O classico é o acesso a banco de dados e a arquivos.mas coisas como cnab, webservices, ETF estariam aqui.
Recursos = recursos usados , o bando de dados em si mesmo (não o SGDB) , arquivos de salvaguarda, logs, qualquer coisa que a aplicação necessite para funcionar que pode ser produzida por ela ou não.

Numa aplicação web tipica:

Cliente = Browser
Apresentação = JSF ou Struts ou Spring MVC ou qq "framework web"
Negocio = Serviços, entidades e outras classes de dominio (validação, specification, value object , etc…)
Integração = Hibernate , qq framework ORM , JDBC puro , leitura de xml, etc…
Recursos = Banco de Dados e arquivos de configuração

É a primeira vez que vejo uma explicação bem clara e nada confusa em nosso idioma. Parabéns!

Parabéns Taborda!
Gostei da explicação.
Espero que a confusão agora termine depois dessa postagem e que os usuários finalmente discutam MVC e sua maneira de funcionar.

djemacao:

analyser:

Como foi muito bem falado pelo “Shoes”, Camada e MVC são diferentes, tenham isso na cabeça, e Camada tb difere entre “Tier” e “Layer”, uma coisa que acaba de vez com a confusão de camada e MVC é simples, eu posso ter MVC em apenas UMA camada, pronto, a partir disso esta claro que MVC é diferente de CAMADAS. Sugiro ler o artigo do Shoes citado neste post (fragmental) e ler novamente a reposta do Sergio Taborda.

Um problema destes conceitos é o seguinte, a maioria tem o conceito errado sobre MVC e Camadas, então como a maioria explica errado acabamos achando que a minoria que explica certo esta errada.

[]s

Camada ou não camada? Layer ou tier? Bom, vamos aos fatos. Falando de Java? Leiam o BluePrints:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html

Podemos SIM, dizer que cada parte do MVC é uma camada (layer), ou traduz de outra forma agora?

Concordo bastante com o que vc diz, e todas as discuções se voltam na maioria das vezes a traduções e interpretações diferentes, quando disse que pode ter MVC em uma camada só, me referia a Tier por exemplo, e não fui muito bem claro, agora não concordo com cada parte de um MVC pode ser uma Layer, não vejo um sistema real que divida em duas layers por exemplo View e Controller, se considerarmos por exemplo o básico “Apresentação/Aplicação/Negócio/Persistência”, ou seus derivados, enfim não vejo essa seraparação de MVC sendo cada parte uma camada, mesmo se tratando de layers.

analyser:

djemacao:

analyser:

Como foi muito bem falado pelo “Shoes”, Camada e MVC são diferentes, tenham isso na cabeça, e Camada tb difere entre “Tier” e “Layer”, uma coisa que acaba de vez com a confusão de camada e MVC é simples, eu posso ter MVC em apenas UMA camada, pronto, a partir disso esta claro que MVC é diferente de CAMADAS. Sugiro ler o artigo do Shoes citado neste post (fragmental) e ler novamente a reposta do Sergio Taborda.

Um problema destes conceitos é o seguinte, a maioria tem o conceito errado sobre MVC e Camadas, então como a maioria explica errado acabamos achando que a minoria que explica certo esta errada.

[]s

Camada ou não camada? Layer ou tier? Bom, vamos aos fatos. Falando de Java? Leiam o BluePrints:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html

Podemos SIM, dizer que cada parte do MVC é uma camada (layer), ou traduz de outra forma agora?

Concordo bastante com o que vc diz, e todas as discuções se voltam na maioria das vezes a traduções e interpretações diferentes, quando disse que pode ter MVC em uma camada só, me referia a Tier por exemplo, e não fui muito bem claro, agora não concordo com cada parte de um MVC pode ser uma Layer, não vejo um sistema real que divida em duas layers por exemplo View e Controller, se considerarmos por exemplo o básico “Apresentação/Aplicação/Negócio/Persistência”, ou seus derivados, enfim não vejo essa seraparação de MVC sendo cada parte uma camada, mesmo se tratando de layers.

Essa discussão está longe do fim, mesmo porque, o pós DDD criaram várias “normas” sobre como o que deveria ser layer. Talvez o que o sergiotaborda interprete em relação a uma arquitetura de cubo seja mais fácil de entender. Porém, irá de encontro a explicação do blueprints se pensar no layer como “andares”, porque MVC não seria bem isso. Entretanto, se pensar no MVC Model 2 (e não MVC puro), ele não está totalmente isolado em uma Presentation Layer, seguindo o raciocínio do sergiotaborda. Penso sempre que, ao criarem essas normas no DDD, dá a impressão de desacoplamento total entre as camadas, o que no MVC Model 2 não existe. Também não posso dizer que os frameworks Java são o MVC Model 2 como a Sun pregou, pois suas características podem se diferir no MVC Model 2.
No fim das contas, vejo que MVC se tornou uma buzzword que todo framework quer dizer que é, mas cada framework, inclusive de cada linguagem, possui um MVC com características diferentes, interpretações diferentes, o que nos leva a pensar se realmente o MVC é necessário no nome.

Olá, meu Deus do céu que indefinição. E agora? MVC dentro Layer ou várias Layer dentro do MVC? :roll: :?: :roll:
E agora, quem poderá nos defender? :shock:

Só posso parabenizar o GUJ por presentear essas discussões beneficiosas a todos os companheiros!
Fico no aguardo por respostas!

Não sei se onde vc tirou isso (quer dizer, sei, mas vamos fingir que é irrelevante)
DDD é para o Domain. O Domain , o dominio é palavra que designa um andar. Chamado normalmente de “negocio”.
A ironia é que “negocio” está errado. Sistemas não têm negocio, têm dominios. Empresas têm negocios. Pessoas têm negocios.
A abstração do negocio, a “binirização” do negocio é o dominio. Esta nomenclatura é antiga. Não foi inventada pelo DDD. O DDD apenas diz que vc pode guiar seu desenvolvimento focando-se principalmente no dominio.
Mas para que fique claro: dominio é um andar: Cliente , Apresentação , Dominio , Integração, Recursos. É o mesmo andar que se chama também de “negocio”.

Está sim. Ele está todo na presentation layer (Andar de Apresentação).
O problema aqui é com o conceito de MVC2 - que quase ninguem entendeu direito.

Primeiro que tudo, o que seria o MVC1 ? É um outro tipo de MVC ? Quandos ha afinal ? Dizem que o JSF é o MVC3, e ai ?
Só existe um tipo de MVC. MVC é um padrão. Apenas existe um.
O que existe são 3 formas de o implementar no andar de apresentação de uma aplicação web em java.

MVC1 ( a primeira tentativa)
Crie-se uma forma de interagir com o protocolo HTTP chame-lhe Servlet. Crie uma maneira dos Servelts cooperarem. Chame-lhe Servlet Container.

Quem recebe os dados ? um servlet. Quem processa os dados ? um servlet. Quem manda a resposta ? um servlet ?
No modelo não-MVC um servlet só - uma classe só - faria tudo. No MVC 1 um tipo diferente de servlet fará cada coisa.
Como o recebimento de dados já é tratado pelo container ( que tradus HTTP para objetos dentro do request) só precisamos implementar um servlet para o controle e um para a resposta. Este é o modelo MVC1.

Mas implementar um servlet para resposta escrevendo HTML na mão dentro do servlet é uma porcaria… dai veio a ideia do JSP.
O JSP é um servlet especial que será compilado a partir de um arquivo especialmente formatado. Isto simplifica muito a implementação do servlet de resposta. O mecanismo serlet de controle + jsp de resposta é o modelo MVC2.
O servlet de controle é muito simples de padronizar e precisamos apenas de uma classe desse tipo. Por isso vários frameworks surgiram para simplificar ainda mais o MVC2 porque agora vc nem precisa mais implementar o servlet de controle ( apenas um pedaço dele) e o jsp.

O modelo MVC3 ( do jsf) introduz o conceito de evento. Este é um conceito que existe no padrão MVC não não era necessário no MVC1 e 2. ( ou melhor, o evento era implicito no prioprio request. O request é o evento).
No modelo MVC3 o request não é mais o evento, o evento é uma coisa em si mesma. Não ha mas JSP e sim um mecanismo de definir a resposta. Definir, não renderizar. O MVC3 isola o C num servlet de controle especial ( o servlet do JSF) o modelo no managedbean e a view num arquivo de face ( que pode ser implementado em jsp, mas isso é um detalhe tecnologico).
Estas coisas interagem pelo modelo MVC do padrão comum , via eventos.

Nada disto sai fora da camada de apresentação. A View no é o HTML do browser, a view é o servlet/jsp/mecanismo que renderiza a resposta. É um detalhe que seja HTML. poderia ser xml, soap, json, etc…

E o ajax ? perguntará vc… o Ajax é um MVC do andar cliente. O Ajax funciona apenas no browser. Quando o ajax consulta o servidor, ele está consultando o model ( do ponto de vista dele é o model) que invoca a view do andar de apresentação e ai vai…
São dois MVC trabalhando juntos. Um no cliente e um no servidor.

Antigamente, sem ajax, não havia MVC no cliente e por isso as aplicações eram chatas. RIA nada mais é que levar o MVC para o browser, em javascript e ajax.

Penso sempre que, ao criarem essas normas no DDD, dá a impressão de desacoplamento total entre as camadas, o que no MVC Model 2 não existe. Também não posso dizer que os frameworks Java são o MVC Model 2 como a Sun pregou, pois suas características podem se diferir no MVC Model 2.
No fim das contas, vejo que MVC se tornou uma buzzword que todo framework quer dizer que é, mas cada framework, inclusive de cada linguagem, possui um MVC com características diferentes, interpretações diferentes, o que nos leva a pensar se realmente o MVC é necessário no nome.

À luz que acabei de dizer, nenhuma destas frases faz sentido.

Sergio, vamos deixar de lado um pouco o DDD e seus conceitos. Vamos entender o que seria layer, ao meu ver, no blueprints. Como você mesmo disse, e eu conheço o MVC Model 2 e 1, bem, cada parte, embora esteja trabalhando claro, a apresentação do cliente, são partes que interagem entre si, mas estão separadas de alguma forma. Ao não chamarmos de layer (ao qual traduzimos como camadas), estariamos traduzindo cada parte como o que? Parte? Etapa? Percebe que não estou dizendo que uma Layer do DDD é como uma Layer do MVC, pois sei que não são. Mas questiono o fato de que estão unidas por um lado e separadas por outro. Veja o caso do pessoal que diz matar um DAO e adicionar lógica aonde, no controller? Ou vamos criar um façade aqui para acessar pelo controller assim chamamos de…?
Ao entrarmos com o DDD, situações como aquelas em que alguns defendem o fim do DAO graças a JPA, vejo como uma invasão da Layer no modo DDD de pensar. E quando usamos activerecord?
A meticulosa capacidade de cada um vir aqui e explicar seus pontos de vista não me convencem bem. Isso tudo no Java. Em .Net já vi defensores do DDD fazerem outras coisas estranhas, mas falaremos disso em outra ocasião.
Aguardo a sua explicação. Se quiser, pode desenhar .

PS: Um edit rápido, onde viu que JSF é tido como MVC3?

djemacao:

Sergio, vamos deixar de lado um pouco o DDD e seus conceitos. Vamos entender o que seria layer, ao meu ver, no blueprints. Como você mesmo disse, e eu conheço o MVC Model 2 e 1, bem, cada parte, embora esteja trabalhando claro, a apresentação do cliente, são partes que interagem entre si, mas estão separadas de alguma forma. Ao não chamarmos de layer (ao qual traduzimos como camadas), estariamos traduzindo cada parte como o que? Parte? Etapa? Percebe que não estou dizendo que uma Layer do DDD é como uma Layer do MVC, pois sei que não são. Mas questiono o fato de que estão unidas por um lado e separadas por outro.

Esse conceito de unidas foi vc que inventou. elas não estão unidas.
MVC modelo 1 e 2 acontecem apenas no servidor, apenas dentro do Servlet Container. Não ha como confundir com o browser ou qq coisa exterior ou em outro andar ou nodo.

Não entendi qual é a sua duvida. Oque é um layer ? Layer (andar) é uma separação lógica da responsabilidade dos objetos do sistema. é uma forma de separar Responsabilidade sobre o controle de fluxo. É a versão arquitetural do padrão de design Chain of Responsability. Cada andar é um “container lógico” para as classes que fazem certos trabalhos.

Vc falou para esquecer o DDD.

DDD não é chamado para aqui. Ele restringe-se a um só andar e é uma metodologia de desenvolvimento. Não tem nada a haver com arquitetura.

PS: Um edit rápido, onde viu que JSF é tido como MVC3?

Não lembro. Algum blog de alguém.

Todas porque qualquer parte, tirando a chamada a um banco de dados, web services ou arquivos em geral, acontecem em um Servlet Container ou em um EJB Container. Quando se refere a um layer o que chama de separar responsabilidade? Um MVC separa responsabilidade também. Dizer que MVC não pode ser layer é uma visão um tanto quanto crítica. Só porque o MVC trata de controle de fluxo? Isso que não entendo, porque a palavra Layer não se encaixaria no MVC, em cada parte? Vai me dizer que cada framework que tem por ai não tem uma visão um pouco diferente dessas tais “separações de responsabilidade”?
Não estou nem falando de browser, que apenas recebe os dados ou os envia.

Apenas cito DDD porque o conceito de que a palavra layer no MVC é errônea parte mais de seus defensores. Não digo que a metodologia é ruim, nada disso. Apenas quero entender porque não podemos falar layer. O que me impediria ter uma layer dentro de outra ou chamá-la assim? Estou sendo tão errado que seria um crime isso? Ou o conceito aqui é por ser confuso? É nisso que quero chegar.

Valeu se puder responder.

Abraço

djemacao:

sergiotaborda:

Esse conceito de unidas foi vc que inventou. elas não estão unidas.
MVC modelo 1 e 2 acontecem apenas no servidor, apenas dentro do Servlet Container. Não ha como confundir com o browser ou qq coisa exterior ou em outro andar ou nodo.

Não entendi qual é a sua duvida. Oque é um layer ? Layer (andar) é uma separação lógica da responsabilidade dos objetos do sistema. é uma forma de separar Responsabilidade sobre o controle de fluxo. É a versão arquitetural do padrão de design Chain of Responsability. Cada andar é um “container lógico” para as classes que fazem certos trabalhos.

Todas porque qualquer parte, tirando a chamada a um banco de dados, web services ou arquivos em geral, acontecem em um Servlet Container ou em um EJB Container. Quando se refere a um layer o que chama de separar responsabilidade?

Como eu já disse andar (pare de chamar de layer) é uma separação lógica. “lógica” significa que só existe na cabeça dos desenvolvedores. Na realidade é tudo um conjunto de objetos vivendo no heap da JVM.
Talvez seja dificil de entender, mas eu não sei explicar melhor.

Não fui eu que inventei o MVC nem a nomenclatura de layer nem a sobreposição em camadas.
O que estou dizendo são os factos. Simplesmente MVC não são nomes de 3 layers. É o nome de um padrão de projeto que é utilizado para organizar a implementação dentro de uma layer.
Não é uma critica. É atestar a realidade.

Simplesmente não encaixa. Não é assim. O nome “layer” não pode ser aplicado para essa finalidade.
Ha uma nomenclatura tenica a ser seguida.

Vou. Padrões de Projeto são seguidos por todo o mundo. A implementação, os trade-offs e as nomenclaturas podem ligeiramente
fazê-lo pensar que não, mas é real.

Não sei de onde tirou essa idéia, mas está enganado.
O conceito do MVC , o padrão MVC , e o conceito de camadas não têm nada a haver, nunca tiveram. Esta errada concepção
que se alastrou como fogo na palha por aqui é simplesmente errada. E o fato de haver muita gente que não sabe, ou não entende
não atesta para a sua veracidade, mas sim para a falta de compreensão de OO por parte dessas pessoas. E enfim, atesta um nivel técnico baixo para o pais como um todo.

Não é uma questão de gosto. É algo que simplesmente é assim. A sua unica opção é entender como é. Tentar dizer que está errado não faz sentido. É como vc tentar convencernos que a palavra “não” é usada para concordar com o que as outras pessoas falam. Simplesmente não. Nunca será. Mesmo que algum maluco faça isso e tenha convensido uma duzia de palermas a fazer o mesmo.

Primeiro porque sua lingua mãe não é o inglês. Segundo porque layer não o mesmo conceito que MVC. é como dizer pão e nuvem. Não representam a mesma coisa.

Simples. Layers existem empilhadas. Umas em cima das outras. Não dentro.

Você está confuso sim. Não é crime estar confuso. É crime permanecer confuso.
Você precisa ler mais, estudar mais e melhor até você entender a diferença.

O conceito não é confuso. O conceito é muito simples.

Ok Sergio, façamos o seguinte, me passe o nome dos livros que leu, já que o que menciona é não aceitar layer para cada parte de MVC, agora me prove porque. Citei o blueprints, agora é sua vez de citar bons livros já que acha que não li os bons.
Me desculpe, mas sua capacidade de convencimento é fraca porque mostra explicações, até muito boas, mas as fontes que são mais necessárias ainda não vi. Fora que sempre cita o Java, não conheci o DDD só no Java, conheci no .Net também.
Não paro de chamar de layer porque são assim nos livros. Não dá pra ficar chamando de andar. Desculpe se estou lhe irritando, mas sou chato mesmo .

djemacao:

Ok Sergio, façamos o seguinte, me passe o nome dos livros que leu, já que o que menciona é não aceitar layer para cada parte de MVC, agora me prove porque. Citei o blueprints, agora é sua vez de citar bons livros já que acha que não li os bons.
Me desculpe, mas sua capacidade de convencimento é fraca porque mostra explicações, até muito boas, mas as fontes que são mais necessárias ainda não vi. Fora que sempre cita o Java, não conheci o DDD só no Java, conheci no .Net também.
Não paro de chamar de layer porque são assim nos livros. Não dá pra ficar chamando de andar. Desculpe se estou lhe irritando, mas sou chato mesmo .

O problema é exatamente esse, vários livros estão errados sobre seus conceitos, pq? Pq leram outros livros errados, e assim por diante, é um conceito muito difícil de corrigir, é como uma bola de neve, um explica o conceito errado e assim vai, partindo pelos péssimos professores universitários que temos, não quero generalizar, existem ótimos professores e eu conheço sim, mas também existem outros que não aplicam o conceito certo, e a aprovação desta monografia apresentada neste post, é uma prova disso.

[]s

analyser:

djemacao:

Ok Sergio, façamos o seguinte, me passe o nome dos livros que leu, já que o que menciona é não aceitar layer para cada parte de MVC, agora me prove porque. Citei o blueprints, agora é sua vez de citar bons livros já que acha que não li os bons.
Me desculpe, mas sua capacidade de convencimento é fraca porque mostra explicações, até muito boas, mas as fontes que são mais necessárias ainda não vi. Fora que sempre cita o Java, não conheci o DDD só no Java, conheci no .Net também.
Não paro de chamar de layer porque são assim nos livros. Não dá pra ficar chamando de andar. Desculpe se estou lhe irritando, mas sou chato mesmo .

O problema é exatamente esse, vários livros estão errados sobre seus conceitos, pq? Pq leram outros livros errados, e assim por diante, é um conceito muito difícil de corrigir, é como uma bola de neve, um explica o conceito errado e assim vai, partindo pelos péssimos professores universitários que temos, não quero generalizar, existem ótimos professores e eu conheço sim, mas também existem outros que não aplicam o conceito certo, e a aprovação desta monografia apresentada neste post, é uma prova disso.

[]s

javamaniaco:

analyser:

djemacao:

Ok Sergio, façamos o seguinte, me passe o nome dos livros que leu, já que o que menciona é não aceitar layer para cada parte de MVC, agora me prove porque. Citei o blueprints, agora é sua vez de citar bons livros já que acha que não li os bons.
Me desculpe, mas sua capacidade de convencimento é fraca porque mostra explicações, até muito boas, mas as fontes que são mais necessárias ainda não vi. Fora que sempre cita o Java, não conheci o DDD só no Java, conheci no .Net também.
Não paro de chamar de layer porque são assim nos livros. Não dá pra ficar chamando de andar. Desculpe se estou lhe irritando, mas sou chato mesmo .

O problema é exatamente esse, vários livros estão errados sobre seus conceitos, pq? Pq leram outros livros errados, e assim por diante, é um conceito muito difícil de corrigir, é como uma bola de neve, um explica o conceito errado e assim vai, partindo pelos péssimos professores universitários que temos, não quero generalizar, existem ótimos professores e eu conheço sim, mas também existem outros que não aplicam o conceito certo, e a aprovação desta monografia apresentada neste post, é uma prova disso.

[]s

Eu penso o seguinte, livros não estão errados. São suas interpretações que o são.

Não tenho nem palavras para descrever como essa pensamento é completamente calamitoso.

Se pessoas podem estar erradas e pessoas escrevem livros, obviamente livros podem estar errados. Tão simples assim.

Então. Vc leu o blueprints. E que mais você leu ? leu em ingles ou portugues ? qual é o nivel de dominio que vc tem dessas linguas ?
Não será você que interpretou mal os textos ? Qual livro você leu dizendo que diz que MVC é separação em camadas. O blueprints não diz isso ( por favor cite se vc encontrar onde diz isso )

Não sei onde vamos parar assim …

Já que vc gosta de livros e livros não mentem que tal ler sobre a Inquisição ? afinal se a biblia diz que a terra é quadrada porque raios ela é redonda ? Ela tem que ser quadrada como está nos livros … .e no mapa. o mapa tb é quadrado. É a prova que a terra não é redonda ! … :roll: :roll: :roll: :shock: :shock:

Eu já não sei mais se é ingenuidade ou malicia…

javamaniaco:

analyser:

djemacao:

Ok Sergio, façamos o seguinte, me passe o nome dos livros que leu, já que o que menciona é não aceitar layer para cada parte de MVC, agora me prove porque. Citei o blueprints, agora é sua vez de citar bons livros já que acha que não li os bons.
Me desculpe, mas sua capacidade de convencimento é fraca porque mostra explicações, até muito boas, mas as fontes que são mais necessárias ainda não vi. Fora que sempre cita o Java, não conheci o DDD só no Java, conheci no .Net também.
Não paro de chamar de layer porque são assim nos livros. Não dá pra ficar chamando de andar. Desculpe se estou lhe irritando, mas sou chato mesmo .

O problema é exatamente esse, vários livros estão errados sobre seus conceitos, pq? Pq leram outros livros errados, e assim por diante, é um conceito muito difícil de corrigir, é como uma bola de neve, um explica o conceito errado e assim vai, partindo pelos péssimos professores universitários que temos, não quero generalizar, existem ótimos professores e eu conheço sim, mas também existem outros que não aplicam o conceito certo, e a aprovação desta monografia apresentada neste post, é uma prova disso.

[]s

Desculpe ai os dois que ficaram discutindo é ou não layer, mas sinceramente, não ganhei nada com essa discussão

Amigo, nem todas as discussões e comentários agregam algo de valor, por exemplo seu comentário num agregou em nada tb a discussão.

Eu só sei que estão dificultando demais o que seria simples, só isso.

Exato, esse é o problema.

To começando a realmente achar que Ruby on Rails é onde devo pousar e mudar meu nick pra rubymaniaco :lol: .

Acho que a discussão se volta para o conceito de MVC e Camadas, e não para a linguagem java em específico, mais tai fiquei com uma dúvida agora que vc pode me esclarecer, o conceito de MVC e Camadas no ruby é diferente?

Olá senhores! Boa noite.

Respeito demais a opinião de ambos e não quero que pareça que estou defendendo um lado ou outro mas a explicação do sergiotaborda neste link foi (na minha humilde opinião de quem está aprendendo MVC) uma das melhores explicações detalhadas do que realmente é MVC.

Mas respeito demais a opinião de todos. Tudo que estou aprendendo é com o esforço e boa vontade de todos. Obrigado a todos os companheiros!

sergiotaborda:

javamaniaco:

analyser:

djemacao:

Ok Sergio, façamos o seguinte, me passe o nome dos livros que leu, já que o que menciona é não aceitar layer para cada parte de MVC, agora me prove porque. Citei o blueprints, agora é sua vez de citar bons livros já que acha que não li os bons.
Me desculpe, mas sua capacidade de convencimento é fraca porque mostra explicações, até muito boas, mas as fontes que são mais necessárias ainda não vi. Fora que sempre cita o Java, não conheci o DDD só no Java, conheci no .Net também.
Não paro de chamar de layer porque são assim nos livros. Não dá pra ficar chamando de andar. Desculpe se estou lhe irritando, mas sou chato mesmo .

O problema é exatamente esse, vários livros estão errados sobre seus conceitos, pq? Pq leram outros livros errados, e assim por diante, é um conceito muito difícil de corrigir, é como uma bola de neve, um explica o conceito errado e assim vai, partindo pelos péssimos professores universitários que temos, não quero generalizar, existem ótimos professores e eu conheço sim, mas também existem outros que não aplicam o conceito certo, e a aprovação desta monografia apresentada neste post, é uma prova disso.

[]s

Eu penso o seguinte, livros não estão errados. São suas interpretações que o são.

Não tenho nem palavras para descrever como essa pensamento é completamente calamitoso.

Se pessoas podem estar erradas e pessoas escrevem livros, obviamente livros podem estar errados. Tão simples assim.

Então. Vc leu o blueprints. E que mais você leu ? leu em ingles ou portugues ? qual é o nivel de dominio que vc tem dessas linguas ?
Não será você que interpretou mal os textos ? Qual livro você leu dizendo que diz que MVC é separação em camadas. O blueprints não diz isso ( por favor cite se vc encontrar onde diz isso )

Não sei onde vamos parar assim …

Já que vc gosta de livros e livros não mentem que tal ler sobre a Inquisição ? afinal se a biblia diz que a terra é quadrada porque raios ela é redonda ? Ela tem que ser quadrada como está nos livros … .e no mapa. o mapa tb é quadrado. É a prova que a terra não é redonda ! … :roll: :roll: :roll: :shock: :shock:

Eu já não sei mais se é ingenuidade ou malicia…

pedromuyala:

Olá senhores! Boa noite.

Respeito demais a opinião de ambos e não quero que pareça que estou defendendo um lado ou outro mas a explicação do sergiotaborda neste link foi (na minha humilde opinião de quem está aprendendo MVC) uma das melhores explicações detalhadas do que realmente é MVC.

Mas respeito demais a opinião de todos. Tudo que estou aprendendo é com o esforço e boa vontade de todos. Obrigado a todos os companheiros! :D

Segue tutorial sobre MVC com SWING utilizando Observer:

http://www.patternizando.com.br/2011/03/design-pattern-observer-com-aplicacao-swing-jse/