renato, faltou um “não” ali hehe e não vi os filmes eu quero … eu preciso
E Thiago, entendeu a colocação do Shoes? Como ele mesmo diz, a persistência de dados em algum lugar não é responsabilidade dos objetos do domínio. Como eu disse, bom senso se faz necessário.
Observe:
void execute() {
Pessoa p = new Pessoa();
Tranformer t = new XmlToObjetctTranformer();
String xml = t.transform( p );
Connection connection = new ConnectionGiver().getConnection();
connection.graveEsteXmlNoBanco( xml );
Messenger m = new ClientMessenger();
messager.sendMessage( "Pessoa gravada no banco com sucesso." );
}
Percebeu quanta coisa essa Action fez? Quantos objetos ela teve que conhecer para fazer o seu trabalho? Não seria muito melhor que os objetos envolvidos fossem mais inteligentes e, ao invés da action pedir a informação para fazer o trabalho, delegasse partes do mesmo para os objetos inteligentes?
O aluno é responsável por se persistir? Então você tem vários objetos de negócio que estão acoplados à camada de persistência (e essa acoplada a eles). Remova esta dependência, deixe que apenas uns poucos objetos saibam sobre a existencia de uma persistência.
(Off-Topic: Esse negócio de acho->logo na sua assinatura tá meio que contra a lógica)
Death and Rebirth é tipo um resumo da série, com algumas bem poucas coisas a mais, tipo no início eles mostram mais ou menos o acidente no pólo sul.
Mas ae, você TEM que ver The End of Evangelion, cara é muuuuuuuuiiiiittttttooooo bom, cara é o máximo pra quem se amarrou na série. Cê tem que ver a última luta da Asuka!!! Até me emociono de lembrar!!!
Pra mim as partes mais demais foram a última luta da Asuka, no filme, e a morte do Kaworu, o último anjo.
Phillip,
Tirar a responsabilidade de se auto-persistir não violaria de alguma forma o encapsulamento?
Afinal, os objetos responsáveis pela persistencia vão ter que conhecer o estado exato daquele objeto para persisti-lo não eh?!
Eu sempre deleguei essa responsabilidade pra outro objeto, mas confesso que tenho esse pequeno grilo de estar violando o encapsulamento até hoje.
O maior problema é o acoplamento (além da confusão infernal de responsabilidades).
Faça poucos objetos acoplados à persistência (não falo nem em SGBD, tô fanaod em poucos objetos que conhecem um DAO, por exemplo) em sua camada de negócios.
Num munod oo “de verdade” (e aí entra o que o jprog falou sobre limitações) seus objetos são semrpe persistentes. A camada de persistência do jeito que é usada hoje é uma gambiarra
Bom adicionar um save num Cliente não é torná-lo inteligente, porque save não é regra de negócio, é persistência. A não ser que você queira o contrário. Certo?
O problema é por exemplo, quando for adicionar uma pessora, na classe de negócio seria um simples add de lista, mas algo por fora em algum momento deverá persistir de fato no disco. O problema é quando, e em que parte do código. Acho que a persistência deva ficar no controlador, isso tem cheiro de AOP não?
eu sei que eu não acompanho esse topico desde o começo e não sou nenhuma autoridade\referencia no assunto:
vendo sobre o assunto de delegar persistencia para uma classe “Cliente” ou “ClienteDAO”… vcs disseram que se eu usar um ClienteDAO para persistir dados de clientes armazenados em uma classe Cliente, eu vou estar violando o enpsulamento??? na prática, que mal há nisso?
acho em minha humilde opinião bem pior deixar que o Cliente se persista.
[OFF-TOPIC LEITURA NÃO OBRIGATORIA]
ah é… poutz… ele não me era estranho e eu tava quebrando a cuca pra me lembrar :roll: valeu Felipe [***/OFF-TOPIC*** LEITURA NÃO OBRIGATORIA]
Achei interessante alguns pontos de vista do autor, mas algumas coisas descordo. Ele sugeriu que uma nova linguagem e ambiente de desenvolvimento fosse criado dessa seguinte forma:
Acho que não, aí você fica preso a um padrão
Facilidade de acesso ao banco o Java tem, alias, nisso o java manda muito bem, ainda mais com o apoio da Oracle e da IBM, que entendem muito bem de BD. Agora ausênsia de tipagem, acho que java poderia ter também. Assim como a linguagem Python que sempre teve.
O java faz isso, claro, não da forma padrão como conhecemos, mas podemos utilizar de forma independente.
Também não conheco como o Delphi implementa isso, mas no Java, não vejo tantos problemas
O java é independete de plataforma e de hardware, alias, não existe melhor ambiente para isso, pelo menos atualmente.
Isso eu concordo, poderia abstrair ao máximo e não ficar preso por muito tempo em coisas secundárias ou preliminares.
[quote=renato3110]
O problema é por exemplo, quando for adicionar uma pessora, na classe de negócio seria um simples add de lista, mas algo por fora em algum momento deverá persistir de fato no disco. O problema é quando, e em que parte do código. Acho que a persistência deva ficar no controlador, isso tem cheiro de AOP não?[/quote]
Exato, e esse é og rande problema da persistência como é hoje, na minha opiunião. Você tem chamads e objetos totalmente artificiais, como apra fazer persistência, quando na verade você sói deveria fazer um lista.add()…
Com AOP+Metadados você poderia identificar quando o cliente de uma classe chama algo que pode mudar seu estado e a parsistir automanticamente.
louds, no google eu achei este artigo do joel, é isso mesmo? Vou ler agora…
eu quero … eu preciso 
