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,