From: Guilherme S. <gui...@gu...> - 2003-08-21 02:46:48
|
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 > |