douglasfs wrote:
POJO Business Logic - Onde se concentra a lógica de negócios, por estar concentrado em um POJO facilita o reuso, manutenção, testabilidade, etc. Eu implementei utilizando o Pattern Command, poderia usar também um Service Layer.

pcalcado wrote:

douglasfs wrote:
POJO Business Logic - Onde se concentra a lógica de negócios, por estar concentrado em um POJO facilita o reuso, manutenção, testabilidade, etc. Eu implementei utilizando o Pattern Command, poderia usar também um Service Layer.

Ou deixar o design procedural de lado e usar um Domain Model

douglasfs wrote:
Mas no geral, vc acredita que essa arquitetura é válida como ponto inicial ?

Com a experiência de quem tem literalmente centenas de Commands para manter: não.
Ainda pretendo fazer um post sobre como refatorar um elefante, mas posso adiantar o seguinte: Não escreva código novo como Command. Crie um domínio e vá utilizando ele toda vez que precisar corrigir bug ou acrescentar algo novo.

Ironlynx wrote:
Philip, esse suposto isolamento é ótimo se vc tem um sistema "normal", digamos assim.Numa aplicação prevalente por possuirmos um único objeto raiz(Um verdadeiro Deus na aplicação), na qual todos os demais dependem(e haja nível de invaginação de objetos...), command ainda rula...

pcalcado wrote:
Cada vez mais eu acredito que persistência transparente em java só o dia que que a JVM for projetada para isso.

A gente tem que quebrar o encapsulamento de uma classe para usar SGBDR, aí uma solução de "persistência transparente" exige que você modele seus algoritmos como Commands, destruindo seu Domain Model e criando código procedural...

dukejeffrie wrote:
Eu acredito que o Command Pattern e um dominio rico nao sao excludentes... mas eu ja tive algumas dores de cabeca com o Hibernate pra dizer que tem vezes que a gente precisa ser condescendente... []

GoF wrote:
Applicability

Use the Command pattern when you want to

* parameterize objects by an action to perform, as MenuItem objects did above. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks.

* specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address space-independent way, then you can transfer a command object for the request to a different process and fulfill the request there.

* support undo. The Command's Execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to Execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling Unexecute and Execute, respectively.

* support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and reexecuting them with the Execute operation.

* structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions.

Thiago Senna wrote:
O que achei mais interessante de se utilizar o command é que vc pode testar a operação que ele executa sem depender de qualquer conteiner que seja, já que o command é um objeto java simples. Assim, fica mais fácil de testar a operação e ainda por cima é mais fácil de reaproveitar.