[Blake-devel] Metodologia?

[Guilherme S. <gui...@gu...>]

Perguntas:
1. Cade os diagramas e os use cases do projeto? Ou ainda nao tem? Ou a
metodologia vai ser "vamu fazendo"...? Sei que eh pesado, nao sei qual a
experiencia de cada um com uml e coisa e tal, mas pq nao comecar de um jeito
mais organizadinho?
2. Alguem ja viu o produto da apyon? http://www.apyon.com.br/apm/index.htm
Existem outros produtos do genero... me falaram que o da apyon ja gera tudo
o que agente ta querendo...

Guilherme

----- Original Message -----
From: "Carlos Villela" <ca...@bl...>
To: <bla...@li...>
Sent: Wednesday, August 20, 2003 4:21 PM
Subject: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de
operações


>
>
> lscheidegger - xdev wrote:
>
> > Ao mapear as interfaces e operações, nós temos que ter em conta que
> > teremos uma situação padrão definida para cada uma delas.
>
> Ok, mas como vc definiria a situacao padrao para a adicao de um objeto,
> por exemplo? IMHO, isto é impossivel - voce nao consegue determinar, de
> forma generica, onde o objeto vai ser adicionado. Mesmo que vc tenha
> informacoes sobre o pai dele, existem diversos casos onde vc nao quer
> adicionar o objeto a um só pai (por exemplo, fazer um determinado
> usuário pertencer a vários grupos).
>
> Acho que se a gente quer fazer um framework que seja, de fato, util em
> todos os casos, nao podemos nos prender a criar "situacoes default", pq
> estas situacoes variam de projeto pra projeto, e de modelo pra modelo,
> principalmente, e mesmo sendo absurdamente customizaveis, ainda nao da
> pra encaixar 100% dos casos. A *unica* situacao default que a gente pode
> ter em mente eh:
>
> - Usuario navega pela aplicacao
> - Usuario seleciona uma operacao
> - Se a operacao precisar de dados para funcionar:
>    - Form apresentado pro usuario
>    - Usuario preenche dados, pressiona submit
>    - Dados sao validados
>      - Se a validacao ocorreu sem problemas:
>        - Executar a operacao
>        - Redirecionar o usuario a uma tela com resultados
>      - Se a validacao apontou inconsistencias:
>        - Re-exibir o formulario, com os dados e dicas de como corrigi-lo
> - Se a operacao puder ser executada sem input:
>    - Executar a operacao
>    - Redirecionar o usuario a uma tela com resultados
>
> Faltou alguma coisa aqui?
>
> > O que fazemos normalmente é criar uma definição padrão para cada
> > interface, operação e propriedade, e mesclamos apenas as diferenças que
> > a entidade/classe que está sendo processada tem.
>
> O problema de fazer isso eh que vc engessa demais a coisa - eu já
> consigo ver usuarios do Blake se perguntando "putz, eu sei que dá pra
> fazer isso, mas eu não faco a menor idéia de como... acho que eu vou ter
> que fazer uma gambiarra aqui, senao eu perco o prazo". Eu nao quero isso
>   - eu quero que todo o processo de criacao de uma aplicacao com o Blake
> seja extremamente aberto, e customizavel.
>
> > Alguns pontos:
> >
> > - O que o blake possibilitará é criar rapidamente a camada de negócio, a
> > camada de negócios 100% das vezes são dados, por mais que vc persista em
> > objetos serializados.
>
> A camada de negocios é feita de regras de negócio e dados, onde as
> regras de negócio operam. Usando a API que eu descrevi no outro e-mail,
> nós resolvemos o problema das duas. No seu modelo, a existência das
> regras de negócios está sendo negada. Por isso vc precisa de AOP - pq vc
>    esta deixando de levar em consideracao a outra metade do que é uma
> camada de negocios ;)
>
> > O fato de vc guardar o id do objeto, em detrimento
> > do  rowid, ou do campo que é primary key, faz com que vc guarde uma
> > referência ao objeto / registro da mesma forma. Em suma, vc sempre terá
> > que guardar um indexador.
>
> Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem
> que seja o endereco de memoria onde eles estao. Mas voce precisa saber
> disso quando esta desenvolvendo um formulario de cadastro de clientes?
> Nao, voce nao deve ter que saber disso. Voce precisa de uma primary key?
> Nao - o unico caso onde eu vejo uma PK sendo util em uma aplicacao eh
> evitar a criacao de objetos com campos-chave duplicados, e,
> sinceramente, nao precisamos do peso conceitual e funcional de uma PK
> pra isso.
>
> > - O modelo relacional não é oposto ao orientado a objeto por mais que
> > seus livros falem isso, eles são complementares. Principalmente pelo
> > fato do modelo orientado a objeto ser extremamente trabalhoso na camada
> > de negócios, onde seu reaproveitamento é pífio. Enquanto que no modelo
> > que estamos propondo não.
>
> OO e R nao sao complementares, mas concordo se vc disser que OO eh um
> superset do modelo relacional. No modelo relacional, existem dados e
> relacionamento, mas nao existe polimorfismo, encapsulamento, mas existe
> identidade.
>
> E de onde vc tirou que "fato do modelo orientado a objeto ser
> extremamente trabalhoso na camada de negócios, onde seu reaproveitamento
> é pífio"? Poderia citar exemplos e fatos que comprovem essa afirmacao?
>
> > Não adianta termos tudo orientado a objeto, estado da arte, se temos uma
> > dificuldade muito grande de reaproveitar o que já fizemos.
> > -Quem deve e será completamente oop, é o framework.
>
> Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte,
> entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework
> quanto o modelo devem ser OOP - se é que a gente quer fazer algo
> estado-da-arte, como vc mesmo diz.
>
> >>>//indica que a primary key é gerada automaticamente e não pode ser
> >>>alterada
> >>>add.hiddenIdentifier(true);
> >
> >>Para tudo que eu quero descer! Objetos nao tem primary key. Isso eh
> >>coisa do banco de dados - e eu sinceramente nem quero usar um, entao
> >>suma com essas nojeiras de modelo relacional da minha frente! :D
> >
> > Entenda isso como um indexador. Eu tb quero usar o prevayler, assim como
> > quero tb usar o oracle. Cara sinto muito, não podemos condicionar o uso
> > do Blake com o uso do Prevayler.
>
> De onde vc tirou isso?
>
> Eu nao disse em nenhum lugar que eu estou condicionando o Blake ao
> Prevayler. Eu so estou dizendo que fazer com que o usuario lide com IDs
> é horrivel. Isso deve ser transparente pra ele - ele nao tem que saber
> se o objeto que ele criou vai ser mapeado pra um banco de dados ou pra
> um punhado de objetos serializados (como eh o caso do Prevayler).
>
> ...ou por acaso vc nasceu com um ID estampado na testa? No mundo real,
> as coisas nao tem IDs. Se voce tem um CPF, voce tem um CPF - Cadastro de
> Pessoa Fisica, um documento, que, obviamente nao eh um ID.
>
>
> >>>//PROCESS
> >>>//define qual é a operação que será chamada após o processamento do
> >>>formulário add.setRedirectOperation("report");
> >
> >>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :)
> >
> > Se tinha sido mapeado, eu nào entendi onde e como.
>
> Quando eu criei novas Actions, e chamei addAction nas instancias de
> ClassDefinition (usuario e grupo).
>
> >>>//define a query de processamento
> >>>add.setQuery("add");
> >
> >>Que query? De onde vem esse "add"? Magica?
> >
> > Não definição padrão, que o wizard responsável interpretará e procurará
> > uma query add, ou qq forma de persistência de dados chamada add. Um dos
> > conceitos do XDev, e que mantemos em arquivos separados as
> > classes/definições e suas queries, dessa forma para um User.java, tem um
> > User.sql. Com relação ao prevayler, teremos que pensar uma alternativa.
>
> Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo.
> Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta
> colocando os _metodos_ do objeto fora dele.
>
> >>>Supondo que essa seja a definição padrão de uma propriedade string:
> >>>string.setLenght(100)
> >>>string.isMandatory(false)
> >>>string.isVisible(true)
> >>>string.setCaption("")
> >>>string.isIdentifier(false)
> >
> >>Hmm... eu gostei mais do modelo de constraints que eu bolei - assim a
> >>gente nao precisa ficar adicionando um >metodo novo na classe Property
> >>sempre que precisar de outro tipo de validacao.
> >
> >>Lembrando:
> >
> >>objeto.addConstraint("propriedade", new Constraint());
> >
> > Esse não é um modelo de constraints, e sim uma definição padrão para uma
> > propriedade do tipo string. Ou seja se vc criar uma propriedade string
> > em sua entidade, e não informar mais nada, ela terá exatamente essa
> > configuração.
>
> De novo, vamos ao debate sobre a "situacao default". Ter uma
> configuração assim nos seus objetos acontecendo por baixo dos panos é
> ruim, pq, afinal, está acontecendo debaixo dos panos.
>
> >>>Essa é a definição padrão de um campo numérico
> >>>(...)
> >>>
> >>>Vamos criar uma entidade Usuário, vou exemplificar apenas a inclusão.
> >>>
> >>>// Cria a definicao da classe
> >>>usuario = new ClassDefinition("Usuario");
> >>>
> >>>// Cria as propriedades que a classe vai ter
> >>>usuario.addProperty("id", Number.class);
> >
> >>AAAAAARGH! :D
> >
> > O que está sendo feito aqui é adicionando uma propriedade, com base em
> > um template.
>
> Nao. O que esta sendo feito aqui é adicionar uma propriedade que um
> Usuario nao tem. Usuarios nao tem IDs. Eles tem coisas como nome, senha,
>    permissoes, grupos a que pertencem, etc, etc, etc. Mas eu nao vejo um
> unico uso pra essa propriedade. Voce poderia me indicar um, que nao seja
> meramente a persistencia?
>
> []'s
> -cv
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Dice.com.
> Did you know that Dice has over 25,000 tech jobs available today? From
> careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
> best hiring companies. http://www.dice.com/index.epl?rel_code=104
> _______________________________________________
> Blake-devel mailing list
> Bla...@li...
> https://lists.sourceforge.net/lists/listinfo/blake-devel
>