Moje osobiste „często wyjaśniane” problemy:
Anty-Wzory
Mieszanie z odłączonymi obiektami (SaveOrUpdate lub Merge plus trochę niechlujnego kodu) zamiast korzystania z DTO. Im bardziej złożone są byty, tym bardziej skomplikowany jest kod. (Oznacza to również, że działa całkiem dobrze z trywialnymi bytami.) Ayende nazywa to również Wzorem Strippera i wyjaśnia problem enkapsulacji.
Niezrozumienie uporczywej ignorancji i pisanie aplikacji NH, jak w przypadku jawnego SQL. Objaw: wywołanie aktualizacji po zmianie obiektu, zastanawianie się, dlaczego zmiany są utrzymywane, nawet jeśli aktualizacja nie została wywołana, zastanawianie się, jak uniknąć zmian, które należy utrwalić.
Niezrozumienie transakcji i wzorca jednostki pracy . Częste anty-wzorce: transakcje niejawne, sesja na operację i sesja na aplikację. Trochę więcej czytania:
Wykorzystanie zdarzeń NH do wprowadzenia logiki aplikacji (np. Śledzenie zmian we wyzwalaczach wstawiania i aktualizacji)
Utwórz jedną klasę na tabelę . Niektórzy ludzie nie rozumieją OOD, inni nie rozumieją projektowania relacyjnego.
Błędy
użycie jeden do jednego zamiast wielu do jednego. Próbowałem to wyjaśnić w tej odpowiedzi .
Korzystanie z funkcji pobierania sprzężenia w połączeniu z SetMaxResult. Moje najnowsze odpowiedzi związane z tym tematem:
Pisanie jednostek zmieniających się . Gdy jednostka nie zwraca dokładnie wartości ustawionej przez NH, jest uważana za brudną i aktualizowana w każdej sesji. Na przykład: zastąpienie trwałej kolekcji NH w ustawieniach właściwości.
IList<Address> Addresses
{
get { return addresses; }
// will cause the addresses collection to be built up from scratch
// in the database in every session, even when just reading the entity.
set { addresses = new List<Address>(value); }
}
int Whatever
{
// will make the entity dirty after reading negative values from the db.
// this causes unexpected updates after just reading the entity.
get { if (whatever < 0) return 0; }
set { whatever = value; }
}
Może być więcej, następuje.