Jacek Czerwinski pisze:
> somebody pisze:
>> Wiktor Zychla pisze:
>
>> nie chodzi o korzystanie z tych gotowych kombajnów. Bardziej chodzi mi
>> o naukę i poszerzenie wiedzy.
>>
>> Przykładowa aplikacja w .net framework to 4 dllki (data, view, mssql,
>> utils) oraz aplikacja webowa. I interesuje mnie, jak sensownie
>> wyświetlać użytkownikowi informacje na temat błędnie wpisanych danych
>> w formularza. Walidatory pól nie są do końca dobrym rozwiązaniem.
>
> Szkoły, czy przynajmniej akcenty są nieco rózne.
> jedna ze szkół "wyjątek to cos wyjątkowego" (w sensie normalne sytuacje
> robi się normalnie) (np. w javie jak biblioteki i JVM z zasady dośc
> mocno optymalizują, tak nikt nie optymalizuje obsługi wyjątków.
> Stwierdzenie stosunkowo oficjalne bo chyba z Joshua Blocha)
>
> Inna szkoła: obsługiwać jak najbliżej.
>
> A może potrzebujesz po prostu dobrych walidatorów?
>
> Zawsze możesz odziedziczyć własne exception, ale to oznacza znów jedną
> więcej zależność po obu stronach throw/catch.

Jestem świadom, że szkół jest wiele i podejścia mogą być przeciwstawne,
dlatego najpierw zapytałem o literaturę, aby móc wyrobić sobie jakieś
własne zdanie.

Walidatory nie wydają się być dobrym rozwiązaniem. Mam np. klienta
(encja, byt z wycinka rzeczywistości), który posiada numer NIP. Jak
rozsądnie powinno wyglądać sprawdzenie czy numer wprowadzany przez osobę
obsługującą aplikację jest poprawny czy też nie?

Teoretycznie może być to walidator w warstwie prezentacji, ale: dla
warstwy prezentacji jest wzorzec MVP i może się ona zmienić. Zresztą mam
wrażenie, że warstwa prezentacji nie jest najlepsza do tego. Więc gdzie?
Niżej? Warstwa logiki? Ale dane są przechowywane w bazie danych i
lepiej, żeby nikt błędnych insertów (w trakcie programowania) nie
zrobił. Więc może procedura składowana dla wstawiania rekordu z
odpaleniem innej procedury dla walidacji? Do zrobienia, jakoś logicznie
uzasadnione.

Ale co, jeśli dla dostępu do danych jest wzorzec repository, a dodatkowo
pole które mamy sprawdzać jest stricto związane z implementowanym
wycinkiem rzeczywistości, a analitycy nie zdążyli jeszcze rozpoznać
pełni algorytmu? (Pomińmy kwestię, że bez specyfikacji nie
programujemy). Powielać kod sprawdzający na kilka warstw?

I jak teraz rozsądnie przekazać informację z np. warstwy logiki
biznesowej albo warstwy danych do warstwy prezentacji, że wypełnione
pole jest niepoprawne?

Widziałem rozwiązanie które polegało na wypełnianiu obiektu (tutaj np.
Client) wartościami od użytkownika a następnie wywołaniem metody
Validate() i zbieraniem listy ewentualnych uwag. Ale czy to obiekt
Client powinien posiadać umiejętność sprawdzania swojej poprawności? Czy
nie jest to przekazanie mu więcej niż jednej odpowiedzialności?

pozdrawiam,

do góry

Wiktor Zychla pisze:
>> Przykładowa aplikacja w .net framework to 4 dllki (data, view, mssql,
>> utils) oraz aplikacja webowa. I interesuje mnie, jak sensownie
>> wyświetlać użytkownikowi informacje na temat błędnie wpisanych danych
>> w formularza. Walidatory pól nie są do końca dobrym rozwiązaniem.
>
> czyli nie chodzi o exception jako takie, tylko w której warstwie
> umieścić walidację danych?

Samo działanie exceptions wydaje mi się być znane. Mam tylko dylematy
natury architektonicznej. Książka Bertranda Meyera zakupiona (szkoda, że
helion nie wznowił druku.. pewnie większość kupuje kolejne książki typu
php&mysql howto:) i powoli wczytuję się w m.in. tematy programowania
kontraktowego i niedotrzymywania ustaleń. Wyjątki będą kolejne. Może to
jakoś rozwieje moje wątpliwości.

pozdrawiam,

do góry

somebody pisze:
> Jacek Czerwinski pisze:
>> somebody pisze:
>>> Wiktor Zychla pisze:
>>
>>> nie chodzi o korzystanie z tych gotowych kombajnów. Bardziej chodzi
>>> mi o naukę i poszerzenie wiedzy.
>>>
>>> Przykładowa aplikacja w .net framework to 4 dllki (data, view, mssql,
>>> utils) oraz aplikacja webowa. I interesuje mnie, jak sensownie
>>> wyświetlać użytkownikowi informacje na temat błędnie wpisanych danych
>>> w formularza. Walidatory pól nie są do końca dobrym rozwiązaniem.
>>
>> Szkoły, czy przynajmniej akcenty są nieco rózne.
>> jedna ze szkół "wyjątek to cos wyjątkowego" (w sensie normalne
>> sytuacje robi się normalnie) (np. w javie jak biblioteki i JVM z
>> zasady dośc mocno optymalizują, tak nikt nie optymalizuje obsługi
>> wyjątków. Stwierdzenie stosunkowo oficjalne bo chyba z Joshua Blocha)
>>
>> Inna szkoła: obsługiwać jak najbliżej.
>>
>> A może potrzebujesz po prostu dobrych walidatorów?
>>
>> Zawsze możesz odziedziczyć własne exception, ale to oznacza znów jedną
>> więcej zależność po obu stronach throw/catch.
>
> Jestem świadom, że szkół jest wiele i podejścia mogą być przeciwstawne,
> dlatego najpierw zapytałem o literaturę, aby móc wyrobić sobie jakieś
> własne zdanie.
>
> Walidatory nie wydają się być dobrym rozwiązaniem. Mam np. klienta
> (encja, byt z wycinka rzeczywistości), który posiada numer NIP. Jak
> rozsądnie powinno wyglądać sprawdzenie czy numer wprowadzany przez osobę
> obsługującą aplikację jest poprawny czy też nie?
>
> Teoretycznie może być to walidator w warstwie prezentacji, ale: dla
> warstwy prezentacji jest wzorzec MVP i może się ona zmienić. Zresztą mam
> wrażenie, że warstwa prezentacji nie jest najlepsza do tego. Więc gdzie?
> Niżej? Warstwa logiki? Ale dane są przechowywane w bazie danych i
> lepiej, żeby nikt błędnych insertów (w trakcie programowania) nie
> zrobił. Więc może procedura składowana dla wstawiania rekordu z
> odpaleniem innej procedury dla walidacji? Do zrobienia, jakoś logicznie
> uzasadnione.
[...]

Musisz wyważyć gdzie walidować. Z jednej strony szkoda pisać tę samą
walidację wiele razy, więc teoretycznie można by ją umieścić tylko w
bazie danych (np. walidować za pomocą trigerów). Ale wywołania bazy
danych są wywołaniami zdalnymi, więc ich nadmiar negatywnie wpływa na
wydajność. Więc przeważnie przesuwa się walidację bliżej użytkownika -
do warstwy logiki lub prezentacji. Dla mnie najwygodniej robi się
walidację w warstwie logiki, ale w aplikacjach ASP.NET (o których
wspomniałeś) szkoda generować żądanie z przeglądarki do klienta WWW po
to, żeby za chwilę powiedzieć, że pole nie może być puste.

Pozdrawiam

--
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

do góry

gregorius pisze:

> Musisz wyważyć gdzie walidować. Z jednej strony szkoda pisać tę samą
> walidację wiele razy, więc teoretycznie można by ją umieścić tylko w
> bazie danych (np. walidować za pomocą trigerów). Ale wywołania bazy
> danych są wywołaniami zdalnymi, więc ich nadmiar negatywnie wpływa na
> wydajność. Więc przeważnie przesuwa się walidację bliżej użytkownika -
> do warstwy logiki lub prezentacji. Dla mnie najwygodniej robi się
> walidację w warstwie logiki, ale w aplikacjach ASP.NET (o których
> wspomniałeś) szkoda generować żądanie z przeglądarki do klienta WWW po
> to, żeby za chwilę powiedzieć, że pole nie może być puste.

Przez to też idę w kierunku generatorów (xml + templates + python =>
c#). Ale mimo to nie mogę sobie pozwolić na syf w kodzie.

Staram się to wypośrodkować, tylko trudno to zrobić bez konkretnych
podstaw w wiedzy.

pozdrawiam,

do góry