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!!!