Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
Encje
Encje są prawdopodobnie najważniejszymi elementami modelu domeny. Reprezentują najistotniejsze obiekty domeny problemu, czyli te, które mają własną tożsamość.

Dwie encje o różnych identyfikatorach są różnymi obiektami. Tak przynajmniej można wyczytać w mądrych książkach. Jak to się jednak ma do praktyki?

W DDDSample porównywanie encji zrealizowane jest za pośrednictwem specjalnego interfejsu posiadającego jedną metodę sameIdentityAs(T other). Wszystkie klasy reprezentujące encje implementują ten interfejs porównując klucz biznesowe.

Dodatkowo wszystkie one implementują także metody equals i getHashCode na bazie zawieranych danych.

W DDDSample.Net postanowiliśmy przyjąć odmienną koncepcję. Polegamy na ORM-ie i jego implementacji Identity Map w kwestii zapewnienia, że dwie instancje encji o tym samym kluczu są w rzeczywistości jednym obiektem na stercie. Dzięki temu możemy korzystać z domyślnych implementacji Equals i GetHashCode opartych o fizyczne adresy w pamięci.

Więcej na ten temat możecie poczytać na dddsamplenet.blogspot.com

Opublikowane 17 października 2009 07:52 przez simon

Komentarze:

# Encje @ 17 października 2009 11:13

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dotnetomaniak.pl

# re: Encje @ 20 października 2009 12:12

Dwie uwagi vel pytania dotyczące implementacji i wydajności:

1. Po pierwsze czemu nie implementujecie interfejsu IEquatable<T>;

2. Nie bardzo mi się podoba (ocena subiektywna zatem) sposób oceny identyczności encji z wykorzystaniem Linq oraz yield. Czy robiliście testy wydajnościowe np. dla porównania 1000 elementów według proponowanych według rozwiązań versus porównanie wszystkich pól "ręcznie" versus porównanie klucza?

arkadiusz.wasniewski

# re: Encje @ 20 października 2009 13:25

1. Hmmm. Szczerze mówiąc nie pomyślałem o nim, natomiast teraz jak tam myślę, to nie mogę wykombinować czym on się różni od zwykłej implementacji Equals? W sensie jak implementuje IEquatable<T> to i tak raczej dla spójności muszę zaimplementować Equals... chyba że nie? Nie mam doświadczenia z wzorcami użycia IEquatable:(

2. Nie robiłem testów. Porównywanie klucza odpada, ponieważ chodzi o obiektu Value Object która mogą takowego w ogóle nie mieć i porównywanie ich wg klucza jest sprzeczne z definicją. Nie sprawdzałem jak to się ma w przypadku różnicy z między porównywaniem po prostu, a z wykorzystaniem iteratora. Tzn jestem pewien, że rozwiązanie z iteratorem jest dużo wolniejsze, ale nie sprawdzałem tego w kontekście czasów pobierania danych z bazy. Postaram się zrobić jakieś testy

simon

Komentarze anonimowe wyłączone