weryfikacje danych w Getter / Ustawiacz lub gdzieś indziej?

głosy
9

Zastanawiam się, czy to dobry pomysł, aby dokonać weryfikacji w pobierające i ustawiające , czy gdzie indziej w kodzie.

To może być zaskoczeniem, jeśli chodzi o optymalizację i przyspieszenie aż kod, myślę, że nie powinno się dokonać weryfikacji w pobierające i ustawiające, ale w kodzie gdzie jesteś aktualizowanie plików lub bazy danych. Czy się mylę?

Utwórz 05/08/2008 o 20:51
źródło użytkownik
W innych językach...                            


8 odpowiedzi

głosy
13

Cóż, jeden z reaons dlaczego zajęcia zazwyczaj zawierają członków prywatnych z publicznymi pobierające / ustawiające jest dokładnie ponieważ mogą zweryfikować dane.

Jeśli masz numer niż może wynosić od 1 do 100, na pewno umieścić coś w seter, że sprawdza, a następnie może rzucić wyjątek, który jest złowionych przez kod. Powód jest prosty: jeśli nie rób tego w seter, trzeba pamiętać, że od 1 do 100 ograniczenie każdym razem, gdy go ustawić, co prowadzi do kodu duplikaty lub gdy go zapomnieć, prowadzi do nieprawidłowym stanie.

Jeśli chodzi o wydajność, jestem z Knuth tutaj:

„Powinniśmy zapomnieć o małej wydajności, powiedzmy około 97% czasu. Przedwczesna optymalizacja jest źródłem wszelkiego zła”

Odpowiedział 05/08/2008 o 20:59
źródło użytkownik

głosy
4

@Terrapin ponownie:

Jeśli wszystko, co masz jest kilka [prosty zestaw publiczny / Pobierz] właściwości ... one równie dobrze może być pola

Właściwości mają inne zalety w stosunku do pól. Są bardziej wyraźna umowa, są szeregowane mogą być debugowany później, są one doskonałym miejscem dla rozszerzenia poprzez dziedziczenie. Clunkier składnia jest przypadkowa złożoność - .NET 3.5 na przykład przezwycięża ten.

Powszechnym (i błędne) praktyka jest zacząć dziedzinach publicznych, i włączyć je do właściwości później, na „w razie potrzeby” zasadach. To łamie umowę z każdym, kto konsumuje swoją klasę, więc najlepiej zacząć właściwości.

Odpowiedział 08/08/2008 o 01:07
źródło użytkownik

głosy
3

To zależy.

Ogólnie, kod powinien zawieść szybko. Jeżeli wartość może być ustawiona przez wielu punktów w kodzie i zweryfikować dopiero po pobraniu wartości, błąd pojawia się w kodzie, który robi aktualizację. Jeśli ustawiaczy sprawdzania poprawności danych wejściowych, wiesz jaki kod próbuje ustawić nieprawidłowe wartości.

Odpowiedział 05/08/2008 o 20:59
źródło użytkownik

głosy
3

Z punktu widzenia konieczności kod najbardziej w utrzymaniu, myślę, że należy to zrobić jak najwięcej walidacji, jak można w ustawiająca nieruchomości. W ten sposób nie będzie buforowanie lub w inny sposób radzenia sobie z nieprawidłowymi danymi.

Po tym wszystkim, to jakie właściwości są przeznaczone dla. Jeśli wszystko, co masz jest kilka właściwości, takie jak ...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

... to równie dobrze może być pola

Odpowiedział 05/08/2008 o 20:59
źródło użytkownik

głosy
1

Staram się nigdy nie pozwól moje obiekty wprowadzić nieprawidłowy stan, więc ustawiaczy zdecydowanie musiałby walidacji, jak również wszelkich metod, które zmieniają stan. W ten sposób nigdy nie trzeba się martwić, że obiekt mam do czynienia z jest nieprawidłowy. Jeśli trzymać swoje metody jak granice walidacji, wtedy nie musisz się martwić o ram walidacji i IsValid () wywołań metod posypane wszędzie.

Odpowiedział 23/09/2008 o 20:44
źródło użytkownik

głosy
1

Chciałbym wdrożyć IDataErrorInfo i umieścić moje logiki sprawdzania w błąd i [columnName] właściwości. W ten sposób, jeśli chcesz sprawdzić programowo, czy wystąpi błąd można po prostu przetestować jedną z tych właściwości w kodzie, czy można oddać walidacji off z obowiązującymi w Web Forms, Windows Forms lub WPF danych.

„ValidatesOnDataError” Wiązanie WPF właściwość czyni to szczególnie łatwe.

Odpowiedział 07/08/2008 o 23:24
źródło użytkownik

głosy
1

Może chcesz sprawdzić Domain Driven Design , Eric Evans. DDD ma to pojęcie Specyfikacja:

... wyraźne orzeczenie Wartosc obiektów dla celów specjalistycznych. PARAMETRY TECHNICZNE jest predykatem, który określa, czy dany przedmiot czy też nie spełniają pewne kryteria.

Myślę, że w przypadku braku szybko to jedna sprawa, druga to gdzie zachować logikę walidacji. Domena jest właściwym miejscem, aby zachować logikę i myślę, że Specyfikacja obiektu lub metodę validate na swoich obiektów domenowych byłoby to dobre miejsce.

Odpowiedział 05/08/2008 o 21:03
źródło użytkownik

głosy
1

Walidacja powinna być ujęte oddzielnie lub pobierające ustawiające w sposób walidacji. W ten sposób, jeśli potrzebuje walidacja do ponownego wykorzystania w wielu komponentów, jest on dostępny.

Gdy seter nazywa, taka usługa walidacji powinny być wykorzystywane do dezynfekcji wejście do obiektu. W ten sposób wiesz, wszystkie informacje przechowywane w obiekcie obowiązuje przez cały czas.

Nie potrzeba żadnego rodzaju walidacji dla getter, ponieważ informacje na obiekcie jest już zaufany ważność.

Nie zapisać momentu skasowania do aktualizacji bazy danych !! Lepiej jest nie szybko .

Odpowiedział 05/08/2008 o 20:55
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more