sergiotaborda wrote:eu entendo, mas não acho certo. quem vai por e tirar o carrinho da sessão tem que ser um objeto com acesso à sessão . O mais obvio é o action, mas vc pode criar um terceiro objecto que encapsula o acesso à sessão ( mas acho que isso é over kill)

sergiotaborda wrote:E qual é o problema disso ?
Os pedidos sim têm que ser acessados em qualquer lugar. São classes publicas, não são ?

sergiotaborda wrote:Poderia.
Poderia ser só um repositorio tb. Depende do que é o seu objeto de report.

sergiotaborda wrote:Ok, mas use uma coleção. Não use arrays!

sergiotaborda wrote:A ideia está certa mas o digrama errado. O diamante preto é do lado do pedido, não do cliente. Além disso faltam quantificadores em todo o modelo.

sergiotaborda wrote:acho que vc eastá viajando... O objecto CarrinhoDeCompras é que existe na sessão. O objecto lá dentro não precisa persistir nada em lugar nenhum.

sergiotaborda wrote:A sua frase equivale a "ninguem mais esperto para controlar uma cirurgia ao coração que o proprio dono do coração"
Isso está errado. A compra/venda é uma outra entidade do sistema. Porque o pedido seria capaz ou responsável de manipular essa entidade ? A manipulação conjunta de 2 ou mais entidades indica a necessidade de um serviço ( que já tinha sido indicado na primeira duvida)

sergiotaborda wrote:É como não ver a vantagem de escover os dentes todos os dias, mas ao final de vários anos vc entende a vantagem.
use o serviço. Vc mesmo chegou na conclusão que precisa dele, mas está resistindo. É muito mais simples que ficam gambiarrando o sistema.

sergiotaborda wrote:Sim. qualquer coisa que seja logica de negocio/dominio que aconteça numa action é um pecado.

Vc cria uma outra classe. Vc passa a ela os parametros e ela gera o report. A action recebe esse report e mostra. Só isso.

Adolfo Rodrigues wrote:TDD ajuda muito na construção de um design limpo e elegante. Acho que você deveria considerar esta alternativa...

sergiotaborda wrote:

hlegius wrote:
QueryResult result = repositorio.findActive(); result.count() // quantos são result.find() // o primeiro encontrado result.list() // todos os encontrados result.isEmpty() // encontrou algum ? if (result.count()>0){ // ou !result.isEmpty() for (Produto p : result.list()){ print(p.getName()); } }

repare que result.count() é mais eficiente que fazer o select todo
vc só irá fazer o select em list() se souber que ha alguma coisa para ler. ( isto é um exemplo, no codigo real vc faz o for e pronto)

Outra forma de usar

// todos os produtos Collection produtos = repositorio.findAll().list(); // quantos produtos int quantos = repositorio.findAll().count(); // Todos os produtos ativos Collection produtos = repositorio.findActive().list(); // quantos produtos foram vendidos o mes passado ? Month month = Month.current().previous(); // objeto de exemplo só para que se entenda int quantosVendidos = repositorio.findSelled( month.start(), month.end() ).count();

sergiotaborda wrote:O Hibernate funciona exactamente assim porque é uma implementação de DomainStore. Usar QueryObject com DomainStore ou DAO é natural.
Mas isso não significa que vc tem que espalhar as suas Criteria pelos seus Actions. Isso o hibernate não o obriga a fazer.
Vc pode criar um repositorio que chama o hibernate tranqüilamente. (aliás vc deve fazer isso se gosta de codigo mantenivel )

O repositorio que use hibernate é responsável por montar os criteria com base nos parametros e passar ao hibernate.
Implementar um QueryResult baseado no query do hibernate tb é simples, já que o Criteria já implementa os vários métodos diferentes ( ele já otimiza as chamadas da forma que estavamos falando).

sergiotaborda wrote:Exatamente. esse é o papel principal do repositório. Ele tem outras vantagens, mas todas derivam dai.

sergiotaborda wrote:vc está simplesmente seguindo o Principio de Separação de Responsabildiade, em particular Encapsulamento, que é uma prática comum do OO.

sergiotaborda wrote:Ah! agora entendi o seu ponto. Vc acha que isso são pesquisas especializadas.
Não. São 3 métodos fazendo a mesma pesquisa e retornando informações diferentes dela.

Em um projeto onde vc tivesse a pesquisa "usuáriosAtivos" vc teria

findUsuariosAtivos : List
getFirstusuarioAtivo : usuario
countUsuariosAtivos : int

Para cada pesquisa vc teria 3 metodos. Para N pesqusias vc teria 3N métodos.
Com o outro modelo vc agrupa os métodos em um objeto de retorno. Então vc tem N pesquisas e N métodos.
muito mais simples , não ?

public class Repositorio { public QueryResult findActive(){ // não executa nada return new SQLQueryResult (datasource); } } public class SQLQueryResult <T> implements QueryResult<T>{ DataSource datasource; ListQueryResult (DataSource datasource{ this.datasource = datasource; } public T find (){ ResultSet rs = execute("SELECT TOP 1 * FROM table ... "); if (rs.next){ return readObject(rs); } else { return null; } } public Collection<T> list(){ ResultSet rs = execute("SELECT * FROM table ... "); List all = new ArrayList(); while (rs.next){ all.add(readObject(rs)); } return Collections.unmodifiableCollection(all); } public int count (){ ResultSet rs = execute("SELECT count(1) FROM table ... "); rs.next return rs.getInt(1); } public boolean isEmpty (){ return this.count() == 0; } }

sergiotaborda wrote:Não. Nada disso.
O QueryObject não faz nada. Ele é apenas um conjunto de dados. Um criteria do hibernate é um QueryObject.
O String SQL passado no statement é um QueryObject.

sergiotaborda wrote:Agora, o QueryObject tende a ser mais complexo. A ideia é vc poder pedir aquelas 4 informações de forma combinada algo assim
QueryObject q = QueryObject.for(Product.class). where("name").eq(name). and("active").isTrue(). and("selled").in(intervalo)

Ai vc passa para o método find() e pronto. Bácisamente o seu repositorio começa a ter um só método. Só que isso destroi o repositorio. O objectivo do repositorio é manter e conter a contrução do QueryObject

sergiotaborda wrote:aposto que isso não era um repositorio e sim um DAO. Pela simples razão que os repositorios não recebem QueryObject complexos ( como já expliquei ) e Criteria é um objeto complexo.
Isso que vc descreveu é o que o um DAO ou um DomainStore faria.

sergiotaborda wrote:A Criteria que foi enviado ao objeto veio de onde ?

sergiotaborda wrote:Foi montada por quem ?

sergiotaborda wrote:Quem escolheu os parametros para ela ?

sergiotaborda wrote:Em um sistema como Repositorio , seria o repositorios a fazer isso e a invocar esse objeto que vc descreveu.
em um sistema sem Repositorio , básicamente qualquer classe pode invocar o DAO, logo a construção do Criteria está espalhada pelo sistema inteiro. E isso é um problema. Esse é o problema que o repositorio tenta resolver. ele é um cara "acima" do DAO que sabe como criar Criterias , invocar o DAO, e tratar o resultado.

pcalcado wrote:Um Repositório é uma ilusão de coleção de objetos, não alguém que responde à queries. Se você quer saber quantos objetos estão dentro de um repositório provavelmente para o cliente isto é apenas um atributo deste, não o resultado de uma pesquisa.

pcalcado wrote:E antes de partir para QueryObject, algo *bem* inra-estrutura e fora de DDD, siga a suestão do Evans e faça a dobradinha Specificaction/Repository

pcalcado wrote:Agora se você ainda não leu o livro eu recomendo que o faça antes de tentar qualquer coisa com Domain-Driven Design. Existem muitas fontes de informação completamente distorcidas por aí.

sergiotaborda wrote:Um repositorio ideal ( no sentido de ser proximo da ideia ) teria vários métodos de pesquisa, cada um recebendo um objeto com os parametros da pesquisa e retornando um objeto de resultado. (Como exemplo, pense no statement do SQL. Ele recebe um String como parametro e retorna um ResultSet como resposta).

sergiotaborda wrote:Do ponto de vista do design é mais correto ter um objeto especifico para ser o seu ResultObject. Este objeto terá uma interface mais simples que List e portanto vai libertá-lo de ter de implementar métodos exotiericos como retainAll().

sergiotaborda wrote:Ou seja, invocar resultObject.count() é mais rápido que invocar resultObject.list().size() porque por detrás dos panos vc não está carregando nenhum objeto realmente.

O repositorio não retorna os objetos de dominio. Ele retorna o resultado da pesquisa. (..)

Agora, para um repositorio que use JDBC vc pode implementar as coisas de forma diferente. count , por exemplo, executaria um select diferente que apenas retorna a contagem de itens sem ter que ler os itens ( é isso que vc quer). isEmpty pode executar o mesmo select e comparar se é zero. find pode limitar a procurar ao primeiro item como um Top 1 (SQL SErver ) ou limit (postgres e outros...)

Mauricio Linhares wrote:

hlegius wrote:Você citou o possível uso de uma factory method, mas como você mesmo disse, eu precisarei buscar os reagendamentos feitos para gerar relatórios depois, por isso preciso deles separados. Entretanto, poderia eu usar uma façade no RepositórioAgendamento para realizar o Reagendamento (finalizar um agendamento e criar outro), ou será que seria desperdício de tempo ? X)

Não é uma boa idéia fazer o repositório depender de uma fachada do sistema, pior, vai terminar criando um ciclo, repositório depende de fachada que depende de repositório.

cmoscoso wrote:Voce parece ter bons argumentos que justificam sua decisao mas ela visa aprimorar um infraestrutura de persistencia que poderia ser preenchida por uma ferramenta de mercado. Se vc vai ter que fazer esse trabalho eu presumo que menor atencao sera dedicada aquilo que gera valor pro cliente.

Mauricio wrote:O ideal é que o seu repositório faça isso (verifique as entidades relacionadas e salve elas de acordo), pois pode vir a acontecer de um reagendamento ser criado fora desse serviço.

Aparentemente, no seu caso, a única coisa que já não está gravada é o "agendamentoNovo", então seria simples fazer o seu repositório de Reagendamentos delegar para o repositório de Agendamentos a gravação do tal "agendamentoNovo".

peczenyj wrote:(..)
Sobre a classe Foto: de a ela um comportamento definido e não fique pensando demais no futuro: quando chegar a hora de refatorar: refatore.

Giulliano wrote:É uma questão de análise. Pra que desperdiçar funcionalidades se a empresa não precisa de controle sobre uma foto.

Imagine num mundo real onde vc ganha R$ 30,00 a hora. E me diz que vai gastar 8 horas criando a tal da Foto e suas implementações onde o que eu te pedi foi controle sobre o produto apenas.

Evitar desperdício é uma boa prática da Visão Ágil.

cmoscoso wrote:+1

List<Foto> fotos;