majowa prezentacja - AMF - adobers.org

Message from discussion majowa prezentacja - AMF

peper

More options May 12, 3:10 am

From: peper <pep...@gmail.com>

Date: Mon, 12 May 2008 00:10:08 -0700 (PDT)

Local: Mon, May 12 2008 3:10 am

Subject: Re: majowa prezentacja - AMF

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On 10 Maj, 13:01, Łukasz Błachowicz <moo...@gmail.com> wrote:

> peper, jesli chcesz porownac wydajnosc, to nie wiem czy widziałes ->http://www.jamesward.org/census/
> Zreszta ogole moze warto byłoby to pokazac, choc teraz to moze troche
> za pozno ... :) uups

Tak, znam to.

> >> I w ogóle powód i zasadność stosowania mapowania klas.

> Hmm, znaczy jestes na nie, czy na tak ? :)

No nie zawsze ma to w ogóle sens. Kiedy używam gdzieś pomiędzy 150 a
170 różnych obiektów danych (z grubsza tyle ma baza) to najwygodniej
jest jak we Flexie maksymalnie dużo jest geneorwane "w locie".

Mapowanie klas @Entity na Flexowe jest fajne, bo można robić coś w
stylu

public void saveUser(User usr) {
entityManager.merge(usr);

}

natomiast łamie to zasady bezpieczeństwa i dobrego projektowania -
powinno się przesyłać proste obiekty (Value Objects) tworzenie
duplikatów klas i "przepisywanie" do nowych obiektów jest takie sobie.
Już szybciej zmapować to tablicy asocjacyjnej.

Istnieją też sytuacje, kiedy użytkownik w zależności od uprawnień
widzi lub nie pewne parametry obiektu. Czasem jest to ustalone dla
ról, wtedy wystarczy przepisać każdą klasę dla każdej roli. 5 ról i 40
klas to tak koło 200 klas - nie jest źle. Czasem natomiast trzeba mieć
możliwość ustalania, które pola są widoczne dla którego poziomu
uprawnień z możliwością dodawania nowych ról i uprawnień a wtedy w
ogóle nie widzę miejsca na mapowanie klas.

Pomijam już tak oczywisty problem, że w gridzie wystarczą 4 pola
obiektu, który możę ich mieć kilkanaście. Po co przesyłać całość?
Użytkownik może sobie chcieć zaznaczyć, które pola chce oglądać w
gridzie.

Oczywiście rozwiązaniem powyższych problemów jest przesyłanie zawsze
takiego samego obiektu, w którym 3/4 pól ma wartosć null. Jaki to
jednak daje wymierny zysk?

> >>Da się na amf0 ale to się mija z celem.

> Dlaczego ? Zmienia się coś poza protokołem ?

Z tego co pamiętam nie da się użyć zwykłego RemoteObject, tylko trzeba
to robić "niskopoziomowo". Ale mogę się mylić.

Reply to author Forward