Czy obiekt powinien znać swój identyfikator?

22

obj.idwydaje się dość powszechny i ​​również mieści się w zakresie czegoś, co obiekt może wiedzieć o sobie. Zastanawiam się, dlaczego mój obiekt powinien znać swój identyfikator?

Wydaje się, że nie ma powodu, aby to mieć? Jednym z głównych powodów jego istnienia jest jej odzyskanie, więc moje repozytoria muszą to wiedzieć, a tym samym używać go do interakcji z bazą danych.

Raz też napotkałem problem, w którym chciałem serializować obiekt do JSON dla RESTful API, w którym identyfikator nie wydawał się pasować do ładunku, ale tylko URI i włączenie go do obiektu utrudniało to.

Czy obiekt powinien znać swój identyfikator? dlaczego lub dlaczego nie?

aktualizacja : Warunki

  1. id: Atrybut identyfikatora obiektu. pod względem bazy danych klucz zastępczy nie jest kluczem naturalnym.
  2. Obiekt: Podmiot lub inny jednoznacznie identyfikowalny obiekt w systemie.
ksenoterracid
źródło
1
Aby pozostać abstrakcyjnym, jeśli nie ma powodu do przechowywania informacji, nie przechowuj ich. To po prostu powoduje bóle głowy.
3
Jeśli nie znasz unikalnego klucza obiektu, jak zaktualizowałbyś dane w bazie danych lub pozwoliłbyś użytkownikowi wybrać wystąpienie z listy?
NoChance
@EmmadKareem to, co mówię, to to, że kolekcja (repozytorium) zna identyfikator, więc dlaczego sam obiekt musi to robić. Gdybym renderował listę, prawdopodobnie renderowałbym kolekcję, która zna identyfikator.
ksenoterrakid
Jeśli nie używasz identyfikatora przechowywanego z obiektem i nigdy nie zamierzasz go używać, nie jest to oczywiście konieczne.
GrandmasterB,
@GrandmasterB no cóż, oczywiście używasz identyfikatora, pytanie brzmi, czy przechowujesz identyfikator w pamięci z obiektem i dlaczego.
Xenoterracide

Odpowiedzi:

8

Krótka odpowiedź: Dołączenie identyfikatora obiektu w obiekcie jest koniecznością, jeśli ma zostać skierowany.

W przypadku scenariusza, w którym planujesz użyć kolekcji obiektów i masz plany skierowania pojedynczego obiektu / obiektu, należy podać identyfikator. Mogą jednak wystąpić przypadki, w których naturalny klucz / identyfikator DateTimemoże sztucznie zaspokoić tę potrzebę.

Ponadto możesz mieć swoje DTO jako lekki pojemnik swojego obiektu, który sam w sobie może pomijać / dołączać identyfikator obiektu. Naprawdę wszystkie te opcje naprawdę zależą od przypadków użycia i potrzeb firmy .

Edycja: jeśli chcesz zidentyfikować swój obiekt, musisz mieć identyfikator. Ten identyfikator może być zastępczym identyfikatorem, datą, czasem, itd., Po prostu czymkolwiek, co identyfikuje Twój obiekt od innych w unikalny sposób.

EL Yusubov
źródło
2
dlaczego powinny być zawarte w obiekcie, a nie tylko w kolekcji (zakładając, że kolekcja jest rodzajem słownika)?
Xenoterracide
Chodzi mi o to, że jeśli chcesz zidentyfikować swój obiekt, musisz mieć identyfikator. może to być identyfikator, data-godzina itp. cokolwiek, co identyfikuje twój obiekt na podstawie innych.
EL Yusubov
1
oczywiście moje pytanie dotyczy raczej tego, dlaczego sam obiekt musi być świadomy tego identyfikatora.
ksenoterrakid
aby wyjaśnić nieco, mam na myśli identyfikator zastępczy, zwykle takie rzeczy, jak dane datetime lub vin, są naturalne, a zatem są częścią danych i nie są nazwane id(a przynajmniej nie chciałbym)
ksenoterracid
6

Próbując pozostawić moją odpowiedź tak abstrakcyjną jak twoje pytanie, myślę, że faktycznie odpowiedziałeś na własne pytanie.

Obiekt powinien znać swój identyfikator, jeśli jest to konieczne.

Obiekt nie powinien znać swojego identyfikatora (lub że nawet go posiada), jeśli nie musi.

Jak już wspomniałeś, zdarzają się przypadki, gdy zachowanie obiektu jest niewygodne lub niepotrzebne lub wiadomo, czy jego identyfikator. Są jednak inne przypadki, w których wygodniej jest, aby obiekt wiedział o jego identyfikatorze. Koduj swoje obiekty odpowiednio do ich użycia.


źródło
w jakich przypadkach wygodnie jest mieć świadomość swojego identyfikatora? Zastanawiałem się nad tym i myślałem, że większość z nich może być oparta na takim właśnie sposobie kodowania, być może pętli for używanej do renderowania, obj.ida nie do renderowania samej kolekcji.
ksenoterrakid
1
@xenoterracide - asynchroniczne przeglądanie i aktualizacja rekordów DB jest jednym z przykładów. W niektórych przypadkach nie będę miał wystarczających informacji, aby jednoznacznie zidentyfikować rekord, z wyjątkiem jego identyfikatora, więc sensowne jest zachowanie identyfikatora w obiekcie rekordu.
ale czy to jest przyczyna czy skutek? czy to wymóg? jeśli twoje repozytorium / kolekcja / datamapper (lub jakiś jego łańcuch) jest odpowiedzialne za utrwalanie aktualizacji, a zna identyfikator i jest w stanie go przekazać ... Próbuję zrozumieć, czy istnieje powód, dla którego go następuję, czy istnieje, ponieważ wiele osób korzysta z aktywnego wzorca zapisu.
ksenoterrakid
@xenoterracide - w przypadkach, o których myślę, zdecydowanie była to przyczynowo-skutkowa potrzeba. W niektórych przypadkach, w których byłem, o wiele wygodniej było zachować identyfikator powiązany z obiektem. Twoje pytanie było dobre, ponieważ podważyło podstawowe założenie wielu twórców ludowych. Uczymy się, gdy wnikamy w takie założenia. Z drugiej strony, nie analizuj zbytnio i idź w przeciwnym kierunku. W przeciwnym razie skończysz pisząc święte deklaracje, które załamałeś.
4

Dość często dołącza się identyfikator, ale często stosuje się słowniki, tj. Struktury danych, w których każdy obiekt jest powiązany z jego identyfikatorem, w taki sposób, że można łatwo pobrać ten obiekt, znając odpowiedni identyfikator, ale obiekt nie wie to.

Na przykład, jeśli tworzysz interfejs API za pomocą dwóch metod:

Następnie nie trzeba ponownie wysyłać identyfikatora 452 w odpowiedzi JSON na drugie żądanie. Użytkownik interfejsu API już zna identyfikator.

Arseni Mourzenko
źródło
4

Myślę, że jest to subiektywne i zależy od twojego projektu.

Najczęściej wydaje się, że jest to projekt pochodzący z aktywnego rekordu . W aktywnym rekordzie twoja jednostka ma metody wykonywania operacji na bazie danych, dlatego też musi znać swój identyfikator bazy danych.

Podczas korzystania z innych wzorców, takich jak repozytorium z maperem danych, przechowywanie tych danych w obiekcie staje się niepotrzebne i być może nieodpowiednie.

Weźmy na przykład Personprzedmiot. Nadano mi imię, które może, ale nie musi być unikalne w rodzinie. Ponieważ populacja się powiększyła, nazwiska nie są już unikalne, dlatego opracowaliśmy identyfikatory zastępcze dla coraz większego systemu. Przykłady obejmują: moje prawo jazdy i numer ubezpieczenia społecznego. Nie urodziłem się z przypisanym identyfikatorem, wszystkie te identyfikatory należy złożyć.

Większość z nich nie tworzy dobrych kluczy / identyfikatorów dla oprogramowania, ponieważ nie są uniwersalne. Przynajmniej nie poza ich specyficznym systemem, oczywiście SSN jest unikalny i spójny z administracją zabezpieczenia społecznego. Ponieważ generalnie nie jesteśmy dostawcami tych informacji, nie nazwałbyś ich, idlecz dane, które reprezentują, np SSN. Czasami nawet zawierają w pełni skomponowany obiekt, taki jak taki, DriversLicensektóry może zawierać wszystkie informacje zawarte w prawie jazdy.

Wszystkie ogólne identyfikatory są zatem kluczami zastępczymi w systemie i można je zastąpić odwołaniami do pamięci, zawierającymi tylko identyfikatory, aby ułatwić wyszukiwanie i utrwalanie rekordów.

Ponieważ an idnie jest fragmentem danych pojęciowych, wątpię, aby (ogólnie) należał do obiektu, ponieważ nie pochodzi z domeny. Należy raczej zachować cel, jakim jest identyfikacja obiektu, który nie ma innego sposobu na przedstawienie unikalnej tożsamości. Można to łatwo zrobić w repozytorium / kolekcji.

W oprogramowaniu, jeśli chcesz reprezentować obiekt jako listę lub utrwalić go, możesz po prostu zrobić to z obiektu repozytorium / kolekcji lub innego obiektu z tym związanego. Przekazując program do mapowania danych (jeśli jest osobny), możesz po prostu przekazać .update( id, obj ).

Oświadczenie : Nie próbowałem jeszcze zbudować systemu, który nie zawiera identyfikatora wewnątrz bytu, a zatem może się okazać, że się mylę.

ksenoterracid
źródło
2

Jak zauważył GlenH7 w komentarzu, jest to dobre pytanie, ponieważ podważa to, co wiele osób uważa za pewnik. Uważam jednak, że nawet jeśli pominięcie identyfikatora może wydawać się koncepcyjnie czyste, pragmatyczną rzeczą do zrobienia byłoby utrzymanie identyfikatora z obiektem na jak największej liczbie warstw systemu. Kosztuje niewiele, ale może się przydać, gdy wszystko zaczyna się psuć.

Jednostka może nie musieć znać swojego identyfikatora, tak jak osoba nie musi znać swojego osobistego numeru identyfikacyjnego, numeru prawa jazdy ani żadnego innego identyfikatora, który mógłby być używany w Twojej lokalizacji. Z pewnością można się bez niego obejść przez większość czasu. Mądrze jest jednak mieć przy sobie jakiś dowód tożsamości, na wszelki wypadek.

To samo można powiedzieć o obiekcie. Niezależnie od zawiłości warstwy dostępu do danych obiekt ostatecznie mapuje się na określony wpis w bazie danych. Ten wpis może być jednoznacznie identyfikowalny tylko na podstawie identyfikatora obiektu. Jeśli tak, wolałbym mieć te informacje w dowolnym momencie, bez względu na to, czy debuguję jakiś kod interfejsu użytkownika, pękanie liczb w warstwie biznesowej, samo repozytorium lub system zależny w całej usłudze internetowej. Albo czy przeglądam dzienniki błędów.

W twoim przypadku, jeśli pobierasz tylko dane z bazy danych i przepychasz je przez usługę internetową, pozostawienie identyfikatora może być dobrym rozwiązaniem. Po prostu nie wierzę, że ma to większy sens niż utrzymanie go w ogólnej sprawie.

scrwtp
źródło
2

Masz rację, nie musisz przechowywać identyfikatora w obiekcie, o ile potrzebujesz go znać tylko w kontekście repozytorium.

Sytuacja zmienia się, gdy przekazujesz obiekt do kodu poza tym kontekstem, kodem, który nie zażądał obiektu według identyfikatora (a zatem go jeszcze nie zna), ale potrzebuje identyfikatora do dowolnego celu (np. Do umieszczenia go na liście identyfikatorów, które będą później wymagane z repozytorium, przez jeszcze jeden kod).

W tej sytuacji masz dwie opcje:

  • wprowadzić nowy argument funkcji „id” w całym łańcuchu funkcji między kontekstem repozytorium a funkcją, w której potrzebny jest identyfikator

  • dołącz identyfikator do obiektu

W większości przypadków lepszym rozwiązaniem będzie przechowywanie identyfikatora w obiekcie. Zmniejszy również zmiany kodu, gdy identyfikator jest potrzebny w nieprzewidzianych miejscach, a także może być czasem pomocny przy debugowaniu.

Dlatego to robię, kiedy to robię.

Paul Thomann
źródło