String ou Date - MVC x "Saco de Propriedades"

Programação Java
#1

ola

estava conversando com uma pessoa e eu iniciante no assunto que sou questionei algumas coisas

1º questionei porque ele usa String para datas e não Date ou Calendar?
Resposta: Como vai direto para o banco e exibe na aplicação, não é necessário usar Date ou Calendar.

2º porque na classe X só tem getters and setters, e as regras de negócio e acesso a banco b[/b] ficam em outras classes?
Resposta: Faço isso devido ao MVC, pois se colocar a logica, regra de negócio na classe não preciso do Controller.

com essas respostas fiquei confuso

pois ainda a pouco postei esse tópico aqui

http://www.guj.com.br/posts/list/87991.java

e me disseram para não criar uma classe “saco de propriedades” somente com getters and setters.

e agora o que esta correto?

ou os dois estão corretos,

porem um trabalhando com MVC e o outro com outro metodo

#2

Colega.

Existem algumas correntes de pensamento referente a este caso.

Muitos tentam seguir a OO a risca, colocando o comportamento(métodos) juntamente com o estado(atributo) dentro de uma classe. O que é legal!

Na verdade essa questão de POJO foi uma definição que não permite teóricamente que sejam inseridos comportamento dentro de uma classa POJO.

Já outros acreditam que separar o acesso a dados da lógica de negócios e das entidades seja melhor por questão de manutenção e bla bla bla…

A melhor escolha vai depender do seu ponto de vista em relação ao seu projeto. Ambas as formas funcionam desde que bem aplicadas.

Procure se embasar mais em torno dos Padrões de Projeto e as definições Java em geral! Caso contrário, você vai sofrer muito até conseguir destinguir o potencial de cada solução.

:stuck_out_tongue:

#3

[quote=paulofernandesjr]ola

estava conversando com uma pessoa e eu iniciante no assunto que sou questionei algumas coisas

1º questionei porque ele usa String para datas e não Date ou Calendar?
Resposta: Como vai direto para o banco e exibe na aplicação, não é necessário usar Date ou Calendar.

2º porque na classe X só tem getters and setters, e as regras de negócio e acesso a banco b[/b] ficam em outras classes?
Resposta: Faço isso devido ao MVC, pois se colocar a logica, regra de negócio na classe não preciso do Controller.

com essas respostas fiquei confuso

pois ainda a pouco postei esse tópico aqui

http://www.guj.com.br/posts/list/87991.java

e me disseram para não criar uma classe “saco de propriedades” somente com getters and setters.

e agora o que esta correto?

ou os dois estão corretos,

porem um trabalhando com MVC e o outro com outro metodo[/quote]

A pessoa que lhe disse isso não sabe do que está falando.

Datas devem ser representadas com objetos da classe java.util.Date, implementações de Calendar, etc. Afinal, como ele vai fazer calculos usando estas datas na forma de strings? O banco possui o formato date, o qual o JDBC mapeia para objetos da classe java.sql.Date, que é uma subclasse de java.util.Date

MVC não tem absolutamente nada haver com deixar regras no controller, pelo contrário. As regras DEVEM ficar nas classes de modelo e os controllers somente devem “repassar as coisas” da view para o modelo ou fazer o controle do fluxo com que as views são exibidas.

É melhor esse seu amigo rever os conceitos dele…

#4

Não acredito, que isso seja uma questão de certo ou errado salvar uma data com String

Isso é questão de bom senso mesmo! Se o Java consegue lidar com o recurso, então pq perder tempo transformando uma String em Data! Mas pensando por outro lado. Porque transformar Data em String? hehehe

Se é possivel fazer a conversão de traz para frente ou de frente para traz, então acredito que isso vai depender de qual é o requisito do sistema para se lidar com datas! Apesar de reconher que Data é data e não String… haheheheh

:stuck_out_tongue:

#5

[quote=Zakim]Não acredito, que isso seja uma questão de certo ou errado salvar uma data com String

Isso é questão de bom senso mesmo! Se o Java consegue lidar com o recurso, então pq perder tempo transformando uma String em Data! Mas pensando por outro lado. Porque transformar Data em String? hehehe

Se é possivel fazer a conversão de traz para frente ou de frente para traz, então acredito que isso vai depender de qual é o requisito do sistema para se lidar com datas! Apesar de reconher que Data é data e não String… haheheheh

:stuck_out_tongue:

[/quote]

E quando, por exemplo, o cara precisar fazer uma consulta ao banco de todos os sei la o que que aconteceram entre uma data inicial e uma data final, como ele vai fazer se estiver string lá no banco? Traz tudo do banco e fica criando java.util.Date a partir da string usando SimpleDateFormat e comparando com o intervalo!? :shock:

#6

poxa cada vez me confundo mais!

mas para eu entender vou tentar exemplificar

tenho uma classe Tarefa

nessa classe quero armazenar uma descrição de uma tarefa e a data e hora dessa tarefa

Com a classe Date sem usar os métodos que estão em desuso, fica muito complicado. Ai resolvi usar o Calendar e o GregorianCalendar coisa que para eu que estou iniciando esta super complexo.

mas voltando

como o sistema é bem simples, não encontrei ou classe para isso.

minha pergunta é: devo criar classe para fazer o DAO e as regras de negócio ou devo colocar tudo na mesma classe, ou nenhum do dois?

abraço

#7

Bom quanto a isso no sql ele poderia fazer um cast, todos os bancos que conheço aceitam esse recurso. Mas tbm acredito que a melhor opção para a maioria dos casos é deixar como date mesmo, até para facilitar mais.

#8

Para ser um POJO sua classe não deve implementar ou extender nenhuma classe de nenhum framework externo.
Nada tem a ver com “comportamento dentre de uma classe”.
Algo sem comportamento é o que Fowler batizou de Objeto Anêmico

#9

Se vc modelou o seu sistema e chegou a um modelo com uma unica classe, ok, esse é o seu modelo.
Mas lembre-se que existem coisas que não são responsabilidade do modelo, por exemplo, persistencia.
Então vc vai criar um objeto que ira fazer a persistencia. E assim vai. Objetos devem fazer aquilo que é sua responsabilidade, nada mais.
Seu modelo pode ter uma unica classe, mas não quer dizer que seu sistema tmb tera uma unica classe.
Existem varias maneira de vc implementar isso. O hype do momento é DDD(Domain Driven Development) que me parece uma boa alternativa, mas no seu caso como parece ser algo simples, talvez não seja a melhor solução.
Talvez vc possa usar ActiveRecord mesmo.
De uma busca no site sobre esses assunto que vc vai achar varios posts que podem te ajudar.

[]´s

#10

Para ser um POJO sua classe não deve implementar ou extender nenhuma classe de nenhum framework externo.
Nada tem a ver com “comportamento dentre de uma classe”.
Algo sem comportamento é o que Fowler batizou de Objeto Anêmico[/quote]

Se eu tenho um POJO e depois de algum tempo decido por colocar algum comportamento nele o que ele vai ser?

Um POJO gordo?
Uma classe normal?
Uma classe não anêmica?

A visão do que essa ele vai ser é você quem faz! Fowler defende o modelo dominio, e nesse ponto tem toda razão em considerar um POJO como anêmico…

tudo vai depender do contexto do projeto! Não é atoa que o próprio Fowler descreveu outros padões para a camada de negócios!

#11

[quote=Zakim]Se eu tenho um POJO e depois de algum tempo decido por colocar algum comportamento nele o que ele vai ser?

Um POJO gordo?
Uma classe normal?
Uma classe não anêmica?[/quote]

Nunca se esqueca que POJO eh sigla pra Plain Old Java Object. Nao pra “struct do C com uma sintaxe menos agonizante”. Plain Old Java Objects nao sao uma caçamba onde vc entulha todos os getters e setters que alguem esqueceu de jogar no cestinho do banheiro. Sao objetos. E objetos sao feitos de dados (atributos, propriedades) e operacoes (metodos).

#12

[quote=Zakim]
Se eu tenho um POJO e depois de algum tempo decido por colocar algum comportamento nele o que ele vai ser?

Um POJO gordo?
Uma classe normal?
Uma classe não anêmica?

A visão do que essa ele vai ser é você quem faz! Fowler defende o modelo dominio, e nesse ponto tem toda razão em considerar um POJO como anêmico…[/quote]
Vai ser um POJO não anêmico. Ser POJO ou não nada tem a ver com colocar estado e comportamento na classe. Exemplificando: um EJB só com getters setters não é um POJO.

#13

[quote=cv][quote=Zakim]Se eu tenho um POJO e depois de algum tempo decido por colocar algum comportamento nele o que ele vai ser?

Um POJO gordo?
Uma classe normal?
Uma classe não anêmica?[/quote]

Nunca se esqueca que POJO eh sigla pra Plain Old Java Object. Nao pra “struct do C com uma sintaxe menos agonizante”. Plain Old Java Objects nao sao uma caçamba onde vc entulha todos os getters e setters que alguem esqueceu de jogar no cestinho do banheiro. Sao objetos. E objetos sao feitos de dados (atributos, propriedades) e operacoes (metodos).[/quote]

concordo plenamente! anêmico ou não ele não deixa de ser um POJO! Mas é o desenvolvedor quem decide qual a melhor forma de utiliza-lo! E cabe a ele escolher qual o tipo de “POJO” utilizar (Gordo, magro e seus derivados)

#14

É meio sem sentido usar String como manipulação de datas, quando você usa JDBC e retorna um ResultSet, ele tem métodos getDate(), getTime() e getTimestamp(). Então não há porque não usá-lo.

Muita gente não entende direito o controller, o “C” do MVC. Acho que as pessoas pensam: “se é controller, então é pra controlar TUDO”. Mas não é assim, pense nele como controlador de entrada. Assim, deve ficar mais claro que a única responsabilidade dele é interpretar o que foi recebido pela View, e chamar o model apropriado, que no seu caso é um método do objeto de tipo Tarefa.

Será que fui claro, ou confundi?

#15

ok.

acho que estou começando a entender!

1] devo trabalhar com Date(e seus derivados[entenda Calendar, GregorianCalendar) e não com String para DATAS

2] o meu modelo é uma coisa e a minha programação [no que fiz respeito as classes] é outro.
no meu modelo só encontrei uma classe, mas é quase que certo que precisarei de uma classe para fazer o DAO.
pelo que entendi sobre POJO ele deve conter os métodos getters e setters e as regras de negócio do meu OBJETO
as regras de negócio que são do Sistema devo controlar no Controller

pelo que entendi é isso ai, lógico que resumidamente

obrigado pelas dicas, e caso alguém tenha mais alguma observação a respeito do meu comentário, por favor diga para que eu possa entender!

abraço

#16

Complementando a sua colocação, qualquer classe “deve” conter os métodos de acesso apenas se isso for necessário para seu negócio.

Caso ainda não tenho esbarrado com este post, vale a pena:
http://blog.caelum.com.br/2006/09/14/nao-aprender-oo-getters-e-setters/

#17

Complementando a sua colocação, qualquer classe “deve” conter os métodos de acesso apenas se isso for necessário para seu negócio.

Caso ainda não tenho esbarrado com este post, vale a pena:
http://blog.caelum.com.br/2006/09/14/nao-aprender-oo-getters-e-setters/[/quote]

concordo…

é isso ai mesmo

li o artigo e achei bem legal, explica sobre as más práticas… eu mesmo se não tivesse lido iria criar todos getters and setters, mesmo que nunca os utilizasse

hehe

valeu pela dica

abraço

#18

Esse é um caminho legal para se começar! Com o tempo vc vai refatorando e posicionando melhor sua estrutura.

O importante é sempre separar as responsabilidades…

#19