Olá galera… estou em um dilema vocês acham viavel incluir em um projeto um pacote de negocios o qual tera a classe que faz a comunicação entre o POJO e o banco de dados? e se nesta mesma classe tiver tambem as regras de negocio como validações e tudo mais? E se possivel esta classe abaixo seria uma DAO? Ou caso tenham alguma sugestão… Obrigado a todos…
Olá,
Regras de negócio ficam nos objetosd e negóico. O que você rpecisa é de um DAO que mapeia objetos de negócio em persistência. Dê uma olhada enstes artigos e apresentações:
Valeu amigo, foi de grande valia… ficou claro para mim, pelo menos a principio.
Model–> POJO
View—> Swing
Somente a “Controller”, ficou no ar a seguinte questão, sera que esta classe acima citada cotendo as validações e comunicação com o banco de dados, poderia ficar como “Controller”, ou ela esta fazendo coisas que são de sua responsabilidade?
Bom dia javapaulomg , então a classe que você citou acima pra mim seria um dao mesmo verificando se está nulo o nome do cliente, o Controller pra mim nada mais é que o responsável por ligar a View eo Model, pois, ele fica no meio destes dois, quando alguém da VIEW dispara algo, cai neste controller que faz algumas validações e que sabe quem chamar…
Camada de apresentação ou visualização - Não esta preocupada em como a informação foi obtida ou onde ela foi obtida apenas exibe a informação.
* inclui os elementos de exibição no cliente : HTML , XML , ASP , Applets .
* É a camada de interface com o usuário.
* É usada para receber a entrada de dados e apresentar o resultado
Camada de lógica da Aplicação - É o coração da aplicação . Responsável por tudo que a aplicação vai fazer.
* modela os dados e o comportamento por atrás do processo de negócios
* se preocupa apenas com o armazenamento , manipulação e geração de dados
* É um encapsulamento de dados e de comportamento independente da apresentação.
Camada de Controle - determina o fluxo da apresentação servindo como uma camada intermediária entre a camada de apresentação e a lógica.
* controla e mapeia as ações
se puder dê uma olhada neste link
http://www.macoratti.net/vbn_mvc.htm
[]'s espero ter ajudado
Bom dia Alberto, sem duvida ajudou bastante, e deste já agradeço a atenção. Estive olhando está acalourada discusão no forum e ví que talvez eu utilizasse da ideia de “N camadas”, tipo: “Apresentação/Controle/Modelo/Pesistencia”.
Apresentação —>GUI
Controle -------->Regras de negocio
Model ----------->POJOS
Persistencia ----->DAO
Será que desta forma, ficaria viavel num primeiro momento penso que sim, porem alguel ja teve alguma experiencia semelhante?
Opa então referente a N camadas acho que você deve escolher o que ficar melhor mesmo para sua implementação.
Referente ao seu modelo com 4 camadas, eu sempre ouvi dizer que os DAO’s fazem parte da camada de modelo…
Ao ler seu artigo tambem achei interessante a forma na qual foi formada a camada de DAO dentro do pacote de modelo.
Logo a camada “Controller”, estaria incumbida de tratar das regras de negocio?
Então javapaulomg, no meu ponto de vista e pela figura que tem no tutorial a camada de controller não trata regra de negócio ela apenas direciona para os modelos de dados ou as classes de regra de negócio… O controller no caso seria apenas o responsável pelo fluxo da sua aplicação, tanto de entrada quanto saída…
[quote=pcalcado]Olá,
Regras de negócio ficam nos objetosd e negóico. O que você rpecisa é de um DAO que mapeia objetos de negócio em persistência. Dê uma olhada enstes artigos e apresentações:
http://fragmental.com.br/wiki[/quote]
Se eu estiver usando Hibernate, convém que os objetos persistentes sejam esses mesmos objetos de negócio?
Modelo não é uma Camada, é um componente do MVC:
http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas
DAOs []bnão[/b] fazem parte da Camada de Negócios, mas sim da Camada de Persistência:
http://fragmental.com.br/wiki/index.php?title=Arquitetura_de_Camadas_em_Java_EE
Mas como Modelo é uma abstração para o MVC das outras Camadas, DAO faz parte do Modelo, que não é uma Camada.
Esse link possui alguns conceitos tortos. Me procupa muito quando ele diz que uma das desvantagens do MVC é:
Nossa, especializado em que, programar?
[quote=pcalcado]
Esse link possui alguns conceitos tortos. Me procupa muito quando ele diz que uma das desvantagens do MVC é:
Nossa, especializado em que, programar?[/quote]
Em programar decentemente 
Não é uma obrigatoriedade… Dependendo da complexidade pode valer a pena usar Transactions Scripts… (e não necessariamente seria um POG) e sim uma escolha
Não é uma obrigatoriedade… Dependendo da complexidade pode valer a pena usar Transactions Scripts… (e não necessariamente seria um POG) e sim uma escolha
[/quote]
O problema é que com Transaction Scripts vc não pode implementar Model Driven Domain, ou seja, sua solução fica menos flexível.
Não é uma obrigatoriedade… Dependendo da complexidade pode valer a pena usar Transactions Scripts… (e não necessariamente seria um POG) e sim uma escolha
[/quote]
O problema é que com Transaction Scripts vc não pode implementar Model Driven Domain, ou seja, sua solução fica menos flexível.[/quote]
Ai vai da escolha dele, se ele precisa de flexibilidade ou o não… Só quis levantar mais uma alternativa pra ele…
Não é uma obrigatoriedade… Dependendo da complexidade pode valer a pena usar Transactions Scripts… (e não necessariamente seria um POG) e sim uma escolha
[/quote]
Neste caso o TransactionScript seria um objeto de negocio e daria no mesmo.
Objeto de Negocio != Domain Model
Agora falando sobre Domain Model x TS, exceto quando se sabe exatamente o que se esta fazendo (desenvolvedor/arquiteto experiente) ou quando se esta fazendo algo muito simples (BCRUDzao sem -ou quase- regra de negocio) utilizar TS eh altamente questionavel.
Não é uma obrigatoriedade… Dependendo da complexidade pode valer a pena usar Transactions Scripts… (e não necessariamente seria um POG) e sim uma escolha
[/quote]
Neste caso o TransactionScript seria um objeto de negocio e daria no mesmo.
[/quote]
Pra mim, Transaction Scripts nao são OBJETOS de negócio… já que nao possuem estado…
Mesmo quem não é altamente experiente, deveria perder um tempo pensando em TS x Domain model…
E qual o o problema com objetos stateless? Se voce argumentar que um objeto deve ter estado entao eles nao seriam nem mesmo objetos. Da mesma forma, Facades, de negocios ou nao, geralmente nao tem estado, elas nao sao bojetos de negocio entado?
Creio que esta havendo uma confusao entre bananas e laranjas.
- Objetos de negocio sao objetos com regras de negocio.
- Domain Model e transaction scripts sao duas formas de modelar objetos de negocio.
Quanto ao DM x TS, eu nao entendi seu ponto. Nunca falei que se devia usar A ou B, apenas que o uso de TS eh questionavel.
A grande maioria das pessoas sem experiencia acaba utilizando TSs para tudo por nao conseguir pensar de maneira nao procedural e ainda criam algo como BOs/VOs e achando que sao TS, ou pelo menos utilizando isso como justificativa. Uma pessoa deve ler muito sobre estes conceitos mas a decisao acertada soh vem com a experiencia.
Eu recomendo DMs quando nao se conhece a plataforma e nao eh um sistema simples porque modelar um DM quando tudo que se precisava era um TS eh menos pior do que modelar um TS quando um DM se fazia necessario.
Isso varia da interpretação de cada um
eu penso assim:
Objetos de negocio != Regras de negocio em Objetos
Fachadas não são objetos de negocio na minha opinião…
Domain model e TS sao formas de modelar lógica de negócio…
Se alguem colocar logica de negocio em um Action, temos também um Objeto de negocio? Eu acredito que não… Isso seria um action com logica de negocio…
Eu interpretei da minha forma… então só quis enriquecer o topico pro cara mesmo depois procurar ler sobre o assunto…
claramente temos interpretações distintas dos mesmos termos então não vamos chegar a um acordo…
o importante é mostrar que existem varias formas de se modelar a logica de negoscio seja com domain model ou TS…
[quote=felipec]Isso varia da interpretação de cada um
eu penso assim:
Objetos de negocio != Regras de negocio em Objetos
Fachadas não são objetos de negocio na minha opinião…
[/quote]
Interessante… E qual então é a sua definção de objetod e negócio? Domain Model?
Quando à Façades, a melhor litertura que eu conheço na área, de Eric Evans e Fowler, usa Services e Repositories como objetos de negócio e estas são apenas Fachadase,especialmente, são essencialment esem estado.
Se voce coloca regra de negócio em uma Action está quebrando Camadas e nem sequer entraria no assunto deste tópico, cujo título é “Camada de Negócios” 