Onde vocês costumam implementar a lógica de negócios em um aplicativo desktop?
Estou tentando definir a Arquitetura Lógica da seguinte forma:
Visão:
.GUI
.Ouvinte (Tratam os eventos gerados pelos componentes Swing)
Modelo:
.Domínio (Pojo’s)
.Controle (Trata os pedidos da camada de apresentação)
Persistência:
.IFactoryGateway (A interface IFactoryGateway define os métodos para retornar os Gateway do pacote IGateway)
.IGateway (definem os métodos para incluir, alterar, excluir e pesquisar)
Preciso definir exatamente onde tratar as regras de negócios, mantendo boas práticas para a implementação do projeto.
Até onde aprendi, as regras de negócio devem ser implementadas no domínio. Esses POJOs que citou podem realizar coisas úteis do que somente gets/sets, como validações, por exemplo.
Mas, por favor, não confie no que estou dizendo. Aguarde um pessoal com mais experiência poder ajudá-lo.
Até onde aprendi, as regras de negócio devem ser implementadas no domínio. Esses POJOs que citou podem realizar coisas úteis do que somente gets/sets, como validações, por exemplo.
Mas, por favor, não confie no que estou dizendo. Aguarde um pessoal com mais experiência poder ajudá-lo. [/quote]
Ingrid,
Obrigado pela atenção! O material foi de grande valia!
Não tenho muita experiencia com aplicações Java Desktop. Tenho trabalhado somento com J2EE. Mas como funciona essa sua camada de persistencia, ou seja o tal pacote IGateway?
Como está organizado seu Modelo de Dominio frente o Modelo Relacional?
[quote=ingridfarabulini]
Até onde aprendi, as regras de negócio devem ser implementadas no domínio. Esses POJOs que citou podem realizar coisas úteis do que somente gets/sets, como validações, por exemplo.[/quote]
Essa questão levantanda pela Ingrid fala a respeito de uma crítica de Martin Fowler a alguns padrões documentados pela Sun em seu J2EE Core Patterns, que ele chama de Modelo de Dominio Anêmico. Ele critica sobretudo os Business Object, definindo-os como uma camada de serviços procedurais sobre um modelo de domínio.
Nela você implementaria lógicas de negócio reutilizáveis. Essa camada é altamentes acoplada a camada de acesso a base de dados (DAO) e ao próprio Modelo de Domínio. São pontos negativos esse alto acoplamento e uma certa violação de principios de Encapsulamento. Fala-se que o modelo torna-se menos expressivo e difícil de entender. Seria uma certa escapadinha do paradigma OO.
A parte positiva é sua alta reusabilidade e a centralização da lógica e do estado do negócio.
Já ouviu falar de DDD ? Num modelo estritamente orientado a objetos, a lógica de negócios poderia, muito bem, estar diretamente nos POJOs de domínio (o único problema com isso é que pode dar trabalho para fazer mapeamento objeto-relacional, mas não chega a ser impossível )
Dê uma olhada no livro “Patterns of Enterprise Application Architecture”, do Martin Fowler, para saber um pouco mais sobre como isso funciona, OK ?
[quote=asaudate]Já ouviu falar de DDD ? Num modelo estritamente orientado a objetos, a lógica de negócios poderia, muito bem, estar diretamente nos POJOs de domínio (o único problema com isso é que pode dar trabalho para fazer mapeamento objeto-relacional, mas não chega a ser impossível )
Dê uma olhada no livro “Patterns of Enterprise Application Architecture”, do Martin Fowler, para saber um pouco mais sobre como isso funciona, OK ?
[]´s
[/quote]
Obrigado pela dica! Irei pesquisar sobre o assunto.
Persistência:
.IFactoryGateway (A interface IFactoryGateway define os métodos para retornar os Gateway do pacote IGateway)
.IGateway (definem os métodos para incluir, alterar, excluir e pesquisar)
Preciso definir exatamente onde tratar as regras de negócios, mantendo boas práticas para a implementação do projeto.
[/quote]
Não tenho muita experiencia com aplicações Java Desktop. Tenho trabalhado somento com J2EE. Mas como funciona essa sua camada de persistencia, ou seja o tal pacote IGateway?
Como está organizado seu Modelo de Dominio frente o Modelo Relacional?
Então FrancoC;
Estou utilizando alguns padrões microarquiteturais:
Transaction Script;
Table Data Gateway;
Factory Method;
A camada visão está organizada com a GUI + Ouvinte;
Na camada modelo estou utilizando 2 pacotes:
Domínio (POJO’s, classes de validação, operações, etc)
Controle (possui dependência com o domínio e IFactoryGateway)
public class ControleUsuario {
// pesquisa usuario por login
public List pesquisarUsuario(String login) throws TesteException{
IFactoryGateway factoryGateway = new FactoryGateway();
IGatewayUsuario gatewayUsuario = factoryGateway.getGatewayUsuario();
return gatewayUsuario.pesquisar(login);
}
Na camada persistência tenho:
IFactoryGateway: interface que define os métodos para retornar os Gateway do pacote IGateway.
public interface IFactoryGateway {
public IGatewayUsuario getGatewayUsuario();
public IGatewayVendedor getGatewayVendedor();
}
FactoryGateway: implementa a interface IFactoryGateway;
public class FactoryGateway implements IFactoryGateway{
public IGatewayUsuario getGatewayUsuario(){
return new GatewayUsuario();
}
public IGatewayVendedor getGatewayVendedor(){
return new GatewayVendedor();
}
}
IGateway: interfaces definindo os métodos para incluir, alterar, excluir e pesquisar;
public interface IGatewayUsuario {
public abstract List pesquisar(String login) throws TesteException;
}
Gateway: implementa a interface IGateway;
public List pesquisar (String login) throws TesteException{
Connection con = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try{
con = GerenciadorDeConexao.getConexao();
stmt = con.prepareStatement(SQL_SELECIONA_USUARIO_POR_LOGIN);
stmt.setString(1, login);
rs = stmt.executeQuery();
List listUsuario = new ArrayList();
while (rs.next()){
Usuario usuario = criarUsuario(rs);
listUsuario.add(usuario);
}
return listUsuario;
)