TL; DR:
DTO opisuje wzór przeniesienia stanu. POCO niczego nie opisuje. To inny sposób na powiedzenie „obiekt” w OOP. Pochodzi z POJO (Java), wymyślonego przez Martina Fowlera, który dosłownie opisuje go jako bardziej wyszukaną nazwę dla „obiektu”, ponieważ „obiekt” nie jest zbyt seksowny.
DTO to wzorzec obiektowy używany do przenoszenia stanu między warstwami wzbudzającymi obawy. Mogą mieć zachowanie (tj. Technicznie mogą być poco), o ile zachowanie to nie mutuje stanu. Na przykład może mieć metodę serializacji.
POCO jest prostym przedmiotem, ale „zwykły” oznacza, że nie jest wyjątkowy. Oznacza to po prostu, że jest to obiekt CLR bez domyślnego wzorca. Ogólny termin. Nie jest przeznaczony do pracy z innymi ramami. Więc jeśli na przykład twoje POCO ma [JsonProperty]dekoracje EF, to na przykład argumentowałbym, że to nie POCO.
Oto przykłady różnych rodzajów wzorców obiektów do porównania:
- Model widoku : służy do modelowania danych dla widoku. Zwykle zawiera adnotacje danych, które pomagają w wiązaniu i sprawdzaniu poprawności. W MVVM działa również jako kontroler. To więcej niż DTO
- Obiekt wartości : służy do reprezentowania wartości
- Korzeń zagregowany : służy do zarządzania stanem i niezmiennikami
- Procedury obsługi : używane w odpowiedzi na zdarzenie / wiadomość
- Atrybuty : używane jako dekoracje w rozwiązywaniu problemów przekrojowych
- Usługa : służy do wykonywania złożonych zadań
- Kontroler : służy do kontroli przepływu żądań i odpowiedzi
- Fabryka : służy do konfigurowania i / lub składania złożonych obiektów do użycia, gdy konstruktor nie jest wystarczająco dobry. Służy również do podejmowania decyzji, które obiekty należy utworzyć w czasie wykonywania.
- Repozytorium / DAO : służy do uzyskiwania dostępu do danych
To wszystko są tylko obiekty, ale zauważ, że większość z nich jest na ogół związana ze wzorem. Możesz więc nazwać je „przedmiotami” lub możesz być bardziej szczegółowy na temat jego intencji i nazwać to tym, czym jest. Dlatego też mamy wzorce projektowe; opisać złożone pojęcia w kilku pracach. DTO jest wzorem. Łączny katalog główny to wzorzec, a widok modelu to wzorzec (np. MVC i MVVM). POCO nie jest wzorem.
POCO nie opisuje wzoru. Jest to po prostu inny sposób odwoływania się do klas / obiektów w OOP. Pomyśl o tym jako o abstrakcyjnej koncepcji; mogą odnosić się do wszystkiego. IMO istnieje jednak relacja jednokierunkowa, ponieważ gdy obiekt osiągnie punkt, w którym może służyć tylko jednemu celowi, nie jest już POCO. Na przykład, kiedy oznaczysz swoją klasę dekoracjami, aby działała z jakimś szkieletem, nie będzie już POCO. W związku z tym:
- DTO to POCO
- POCO nie jest DTO
- Model widoku to POCO
- POCO nie jest modelem widoku
Rozróżnienie między nimi polega na tym, aby zachować przejrzystość i spójność wzorów, aby nie przekraczać obaw i prowadzić do ścisłego połączenia. Na przykład, jeśli masz obiekt biznesowy, który ma metody mutowania stanu, ale jest także udekorowany piekłem za pomocą dekoracji EF do zapisywania na SQL Server i JsonProperty, aby można go było odesłać przez punkt końcowy interfejsu API. Obiekt ten byłby nietolerancyjny do zmiany i prawdopodobnie byłby zaśmiecony wariantami właściwości (np. UserId, UserPk, UserKey, UserGuid, gdzie niektóre z nich są oznaczone, aby nie były zapisywane w bazie danych, a inne oznaczone, aby nie były serializowane, JSON w punkcie końcowym interfejsu API).
Więc jeśli miałbyś mi powiedzieć, że coś było DTO, prawdopodobnie upewniłbym się, że nigdy nie był używany do niczego innego niż przemieszczanie się. Jeśli powiedziałeś mi, że coś jest modelem widoku, prawdopodobnie upewniłbym się, że nie zostanie zapisany w bazie danych. Jeśli powiedziałeś mi, że coś jest modelem domeny, prawdopodobnie upewniłbym się, że nie ma zależności od niczego poza domeną. Ale gdybyś powiedział mi, że coś jest POCO, tak naprawdę wcale byś mi nie powiedział.