From: lscheidegger - x. <lsc...@xd...> - 2003-08-21 00:33:07
|
Acho que est=E1 na hora de separarmos as discuss=F5es. De outra forma = cada e-mail ser=E1 um livro =E9 uma queda de bra=E7os em v=E1rias frentes. 1=BA Como ser=E3o definidas as opera=E7=F5es e propriedades; 2=BA Qual ser=E1 a abrang=EAncia do Blake; 3=BA Como faremos persist=EAncia de dados, como relacionaremos registros = x objetos; 4=BA Como e quanto das interfaces ser=E3o mapeadas; Responderei cada quest=E3o em um e-mail At=E9 -----Mensagem original----- De: bla...@li... [mailto:bla...@li...] Em nome de Carlos Villela Enviada em: quarta-feira, 20 de agosto de 2003 16:22 Para: bla...@li... Assunto: [Blake-devel] Re: [Blake-devel] [Blake-devel] - Mapeamento de opera=E7=F5es lscheidegger - xdev wrote: > Ao mapear as interfaces e opera=E7=F5es, n=F3s temos que ter em conta = que=20 > teremos uma situa=E7=E3o padr=E3o definida para cada uma delas. Ok, mas como vc definiria a situacao padrao para a adicao de um objeto,=20 por exemplo? IMHO, isto =E9 impossivel - voce nao consegue determinar, = de=20 forma generica, onde o objeto vai ser adicionado. Mesmo que vc tenha=20 informacoes sobre o pai dele, existem diversos casos onde vc nao quer=20 adicionar o objeto a um s=F3 pai (por exemplo, fazer um determinado=20 usu=E1rio pertencer a v=E1rios grupos). Acho que se a gente quer fazer um framework que seja, de fato, util em=20 todos os casos, nao podemos nos prender a criar "situacoes default", pq=20 estas situacoes variam de projeto pra projeto, e de modelo pra modelo,=20 principalmente, e mesmo sendo absurdamente customizaveis, ainda nao da=20 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 =E9 criar uma defini=E7=E3o padr=E3o para = cada=20 > interface, opera=E7=E3o e propriedade, e mesclamos apenas as = diferen=E7as=20 > que a entidade/classe que est=E1 sendo processada tem. O problema de fazer isso eh que vc engessa demais a coisa - eu j=E1=20 consigo ver usuarios do Blake se perguntando "putz, eu sei que d=E1 pra=20 fazer isso, mas eu n=E3o faco a menor id=E9ia 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: >=20 > - O que o blake possibilitar=E1 =E9 criar rapidamente a camada de = neg=F3cio, > a camada de neg=F3cios 100% das vezes s=E3o dados, por mais que vc=20 > persista em objetos serializados. A camada de negocios =E9 feita de regras de neg=F3cio e dados, onde as=20 regras de neg=F3cio operam. Usando a API que eu descrevi no outro = e-mail,=20 n=F3s resolvemos o problema das duas. No seu modelo, a exist=EAncia das=20 regras de neg=F3cios est=E1 sendo negada. Por isso vc precisa de AOP - = pq vc esta deixando de levar em consideracao a outra metade do que =E9 uma=20 camada de negocios ;) > O fato de vc guardar o id do objeto, em detrimento > do rowid, ou do campo que =E9 primary key, faz com que vc guarde uma=20 > refer=EAncia ao objeto / registro da mesma forma. Em suma, vc sempre=20 > ter=E1 que guardar um indexador. Sim, todos os objetos tem um indexador de uma maneira ou de outra, nem=20 que seja o endereco de memoria onde eles estao. Mas voce precisa saber=20 disso quando esta desenvolvendo um formulario de cadastro de clientes?=20 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=20 evitar a criacao de objetos com campos-chave duplicados, e,=20 sinceramente, nao precisamos do peso conceitual e funcional de uma PK=20 pra isso. > - O modelo relacional n=E3o =E9 oposto ao orientado a objeto por mais = que=20 > seus livros falem isso, eles s=E3o complementares. Principalmente pelo = > fato do modelo orientado a objeto ser extremamente trabalhoso na=20 > camada de neg=F3cios, onde seu reaproveitamento =E9 p=EDfio. Enquanto = que no > modelo que estamos propondo n=E3o. OO e R nao sao complementares, mas concordo se vc disser que OO eh um=20 superset do modelo relacional. No modelo relacional, existem dados e=20 relacionamento, mas nao existe polimorfismo, encapsulamento, mas existe=20 identidade. E de onde vc tirou que "fato do modelo orientado a objeto ser=20 extremamente trabalhoso na camada de neg=F3cios, onde seu = reaproveitamento =E9 p=EDfio"? Poderia citar exemplos e fatos que comprovem essa = afirmacao? > N=E3o adianta termos tudo orientado a objeto, estado da arte, se temos = > uma dificuldade muito grande de reaproveitar o que j=E1 fizemos. -Quem = > deve e ser=E1 completamente oop, =E9 o framework. Discordo - mesmo pq se o que a gente fizer for, mesmo, estado-da-arte,=20 entao o reaproveitamento vai ser uma baba. E, IMHO, tanto o framework=20 quanto o modelo devem ser OOP - se =E9 que a gente quer fazer algo=20 estado-da-arte, como vc mesmo diz. >>>//indica que a primary key =E9 gerada automaticamente e n=E3o pode = ser >>>alterada >>>add.hiddenIdentifier(true); >=20 >>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 >=20 > Entenda isso como um indexador. Eu tb quero usar o prevayler, assim=20 > como quero tb usar o oracle. Cara sinto muito, n=E3o 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=20 Prevayler. Eu so estou dizendo que fazer com que o usuario lide com IDs=20 =E9 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=20 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,=20 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 =E9 a opera=E7=E3o que ser=E1 chamada ap=F3s o = processamento do >>>formul=E1rio add.setRedirectOperation("report"); >=20 >>Huh!? Isso ja nao tinha sido mapeado na Action que eu bolei antes? :) >=20 > Se tinha sido mapeado, eu n=E0o entendi onde e como. Quando eu criei novas Actions, e chamei addAction nas instancias de=20 ClassDefinition (usuario e grupo). >>>//define a query de processamento >>>add.setQuery("add"); >=20 >>Que query? De onde vem esse "add"? Magica? >=20 > N=E3o defini=E7=E3o padr=E3o, que o wizard respons=E1vel = interpretar=E1 e=20 > procurar=E1 uma query add, ou qq forma de persist=EAncia de dados = chamada=20 > add. Um dos conceitos do XDev, e que mantemos em arquivos separados as > classes/defini=E7=F5es e suas queries, dessa forma para um User.java, = tem=20 > um User.sql. Com rela=E7=E3o ao prevayler, teremos que pensar uma=20 > alternativa. Entao esse "conceito" de ter um .sql pra cada .java morre aqui mesmo.=20 Pq, ao fazer isso, vc, alem de estar jogando fora o reuso, esta=20 colocando os _metodos_ do objeto fora dele. >>>Supondo que essa seja a defini=E7=E3o padr=E3o de uma propriedade = string: >>>string.setLenght(100) >>>string.isMandatory(false) >>>string.isVisible(true) >>>string.setCaption("") >>>string.isIdentifier(false) >=20 >>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. >=20 >>Lembrando: >=20 >>objeto.addConstraint("propriedade", new Constraint()); >=20 > Esse n=E3o =E9 um modelo de constraints, e sim uma defini=E7=E3o = padr=E3o para=20 > uma propriedade do tipo string. Ou seja se vc criar uma propriedade=20 > string em sua entidade, e n=E3o informar mais nada, ela ter=E1 = exatamente=20 > essa configura=E7=E3o. De novo, vamos ao debate sobre a "situacao default". Ter uma=20 configura=E7=E3o assim nos seus objetos acontecendo por baixo dos panos = =E9=20 ruim, pq, afinal, est=E1 acontecendo debaixo dos panos. >>>Essa =E9 a defini=E7=E3o padr=E3o de um campo num=E9rico >>>(...) >>> >>>Vamos criar uma entidade Usu=E1rio, vou exemplificar apenas a = inclus=E3o. >>> >>>// Cria a definicao da classe >>>usuario =3D new ClassDefinition("Usuario"); >>> >>>// Cria as propriedades que a classe vai ter >>>usuario.addProperty("id", Number.class); >=20 >>AAAAAARGH! :D >=20 > O que est=E1 sendo feito aqui =E9 adicionando uma propriedade, com = base em > um template. Nao. O que esta sendo feito aqui =E9 adicionar uma propriedade que um=20 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=3D104 _______________________________________________ Blake-devel mailing list Bla...@li... https://lists.sourceforge.net/lists/listinfo/blake-devel |