Czy obiekt powinien znać swój identyfikator?

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.

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.

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.

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:

• http://api.example.com/products/

  Ładuje listę identyfikatorów produktów.

• http://api.example.com/product/452/

  Ładuje produkt o ID 452.

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

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ę.

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.

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ę.