Camada de negocios

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

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…

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

Sim.

http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

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?

pcalcado:

Esse link possui alguns conceitos tortos. Me procupa muito quando ele diz que uma das desvantagens do MVC é:

Nossa, especializado em que, programar?

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

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

O problema é que com Transaction Scripts vc não pode implementar Model Driven Domain, ou seja, sua solução fica menos flexível.

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

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

Neste caso o TransactionScript seria um objeto de negocio e daria no mesmo.

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.

1. Objetos de negocio sao objetos com regras de negocio.
2. 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…

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…

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”

Bom… minha definição de objetos de negócio são objetos (estado e comportamento) que mapeiam logicas de negocio do mundo real…

Domain model tem objetos de negócio e TS se definem pelo nome…

Martin fowler escreveu sobre transactions scripts

Organizes business logic by procedures where each procedure handles a single request from the presentation

Não consigo chamar TS de objetos de negocio hehe… sao scripts procedurais mesmo escritos como objetos em objetos java…

sobre os actions… voce nao respondeu minha pergunta com sim ou nao hehe 8) mas dexa pra la… nao era uma pergunta besta mesmo

bom… tamos saindo do foco do topico hehe daqui a pouco trancam o topico hehe

Uhm, vamos tentar elaborar o ponto. Mapear logica de negocios qualquer programa, em qualquer paradigma pode fazer, concorda? Uma aplicacao em pascal mapeia regras de negócio em funções e estruturas de dados.

Então quando utilizamos os objetos nós apenas os utilizamos para mapear regras de negócio, correto? Agora como fazemos?

No Domain Model nós os vamos mapear através da modelagem de entidades do mundo real em objetos. Adicionando Domain-Driven Design e Domail Driven modeling em geral temos um mapeamento mais próximo do 1-para-1 quanto possivel.

No Transaction Script nós vamos mapear os processos do mundo real em objetos.

Em ambos os modos utilizamos objetos pra modelar regras de negócio, um focado em conceitos como entidades e outro levando os processos.

Meu conceito de objetod e negócio é um objeto que realiza regra de negócio, logo ambos cabem na definicção.

Na verdade eu respondi sim, só que fui muito raso, acho.

Basicamnete utilizar Camadas significa que você vai separar os objetos por responsabilidade em grandes áreas, e geralmente estas áreas são interface, negócios e persistência. Se seu objeto de interface (a Action) possui lógica de negócios significa que você não está utilizando Camadas, ao menos não corretamente.

Este tópico fala em arquitetura de camadas, especificamente sobre Camada de Negócios

Ai que está o meu ponto onde estou sendo meio chato…

Objetos de negócio são os que realizam a lógica de negócio segundo você.

Beleza!

Em sistemas mal projetados (existem muitos) os objetos de negócio seriam aqueles em que o usuário colocou sua regra de negócio, mesmo que seja um action - segundo sua definição. Ou seja, a sua definição está correta desde que o sistema esteja bem projetado, o que não é o caso de muitos.

A minha definição é na verdade bem restrita, mas eu me sinto confortável porque não da margens a alguem chamar um action de objeto de negócio hehe… bom… como ja disse é uma questão mais pessoal…

Sobre o foco ehe… acabmos caindo numa disucssão mais teorica do que prática pra ajudar o autor hehe mas se ele estiver lendo ótimo… Até porque na engenharia de software ainda nos podemos nos dar o luxo de “entender do nosso jeito” (com coerência é claro, mesmo sendo difícil as vezes) e nao ter que decorar definições já feitas… mas isso tem seu ponto negativo também…

[]ś

Sobre o assunto nao se preocupe, o GUJ eh conhecido por nao ser apenas um helpdesk e sim pontod e discussoes. Aidna estamsod entro do topico Camada de Negocios e caso saiamos dele pdoemos criar outro topico para continuar a discussão.

Sobre os sistemas mal projetados, acredito que oproblema eh an cosntrução dos sistemas em si e não no conceito de objetos de negócio. Quando se deparar com um sistema deste tipo creio que o melhor seja avaliar os meritos tecnicos deste, nao restringir um conceito que eh amplo por natureza apenas para nao endossar uma ma pratica. De qualquer forma entendi sua preocupacao.