Zwykły stary obiekt CLR a obiekt transferu danych

POCO = Plain Old CLR (lub lepiej: Class) Object

DTO = Obiekt transferu danych

W tym poście jest różnica, ale szczerze mówiąc większość blogów, które czytam, opisuje POCO w sposobie definiowania DTO: DTO to proste pojemniki danych używane do przenoszenia danych między warstwami aplikacji.

Czy POCO i DTO to to samo?

POCO przestrzega zasad OOP. Powinien (ale nie musi) mieć stan i zachowanie. POCO pochodzi od POJO, wymyślonego przez Martina Fowlera [ tutaj anegdota ]. Użył terminu POJO jako sposobu, aby uczynić bardziej seksownym odrzucenie ciężkich implementacji EJB dla szkieletu. POCO powinno być używane w tym samym kontekście w .Net. Nie pozwól, aby ramy dyktowały projekt twojego obiektu.

Jedynym celem DTO jest przeniesienie stanu i nie powinno ono zachowywać się. Zobacz wyjaśnienie DTO Martina Fowlera, aby zobaczyć przykład użycia tego wzorca.

Oto różnica: POCO opisuje podejście do programowania (staromodne programowanie obiektowe), w którym DTO jest wzorcem używanym do „przesyłania danych” za pomocą obiektów.

Chociaż możesz traktować POCO jak DTO, ryzykujesz utworzenie anemicznego modelu domeny, jeśli to zrobisz. Ponadto istnieje rozbieżność w strukturze, ponieważ DTO powinny być zaprojektowane do przesyłania danych, a nie do reprezentowania prawdziwej struktury domeny biznesowej. Powoduje to, że DTO wydają się być bardziej płaskie niż rzeczywista domena.

W domenie o dowolnej złożoności prawie zawsze lepiej jest tworzyć oddzielne POCO domeny i tłumaczyć je na DTO. DDD (projekt oparty na domenie) definiuje warstwę antykorupcyjną (kolejny link tutaj , ale najlepiej jest kupić książkę ), która jest dobrą strukturą, która wyjaśnia segregację.

Prawdopodobnie jest to dla mnie zbędne, ponieważ wypowiedziałem się już w moim blogu, ale ostatni akapit tego artykułu podsumowuje:

Podsumowując, naucz się kochać POCO i upewnij się, że nie rozpowszechniasz żadnych nieporozumień na temat tego, że jest to to samo, co DTO. DTO to proste kontenery danych służące do przenoszenia danych między warstwami aplikacji. POCO są pełnoprawnymi obiektami biznesowymi z jednym wymogiem, że są ignorantami trwałości (bez metod pobierania lub zapisywania). Na koniec, jeśli jeszcze nie sprawdziłeś książki Jimmy'ego Nilssona, odbierz ją ze stosów lokalnych uniwersytetów. Ma przykłady w języku C # i jest świetną lekturą.

BTW, Patrick Przeczytałem POCO jako artykuł Lifestyle i całkowicie się zgadzam, to fantastyczny artykuł. To właściwie fragment z książki Jimmy'ego Nilssona, który poleciłem. Nie miałem pojęcia, że ​​jest dostępny online. Jego książka jest naprawdę najlepszym źródłem informacji na temat POCO / DTO / Repository / i innych praktyk programistycznych DDD.

POCO to po prostu obiekt, który nie jest zależny od zewnętrznych ram. To jest ZWYKŁE.

To, czy POCO ma zachowanie, czy nie, jest nieistotne.

DTO może być POCO, podobnie jak obiekt domeny (który zazwyczaj byłby bogaty w zachowanie).

Zazwyczaj DTO częściej przyjmują zależności od zewnętrznych ram (np. Atrybutów) do celów serializacji, ponieważ zazwyczaj wychodzą na granicy systemu.

W typowych architekturach typu cebulowego (często używanych w ramach szeroko pojętego podejścia DDD) warstwa domeny jest umieszczana w środku, więc jej obiekty nie powinny w tym momencie mieć zależności poza tą warstwą.

Napisałem artykuł na ten temat: DTO vs Value Object vs POCO .

W skrócie:

• DTO! = Obiekt wartości
• DTO ⊂ POCO
• Obiekt wartości ⊂ POCO

Myślę, że DTO może być POCO. DTO bardziej dotyczy korzystania z obiektu, podczas gdy POCO jest bardziej stylem obiektu (oddzielony od koncepcji architektonicznych).

Jednym z przykładów, w których POCO jest czymś innym niż DTO, jest mówienie o POCO w modelu domeny / modelu logiki biznesowej, który jest niezłą reprezentacją problemu w domenie problemowej. Możesz używać POCO w całej aplikacji, ale może to mieć niepożądane skutki uboczne, takie jak wyciek wiedzy. DTO są na przykład używane z warstwy usługowej, z którą komunikuje się interfejs użytkownika, DTO są płaską reprezentacją danych i są używane tylko do dostarczania interfejsowi danych i przekazywania zmian z powrotem do warstwy usług. Warstwa usługi odpowiada za odwzorowanie obu sposobów DTO na obiekty domeny POCO.

Aktualizacja Martin Fowler powiedział, że takie podejście jest trudną drogą i należy je podjąć tylko wtedy, gdy istnieje znaczące niedopasowanie między warstwą domeny a interfejsem użytkownika.

Podstawowym przypadkiem użycia DTO jest zwracanie danych z usługi internetowej. W tym przypadku POCO i DTO są równoważne. Każde zachowanie w POCO zostanie usunięte, gdy zostanie zwrócone z usługi sieciowej, więc tak naprawdę nie ma znaczenia, czy ma zachowanie.

oto ogólna zasada: DTO == zło i wskaźnik nadmiernie zaprojektowanego oprogramowania. POCO == dobre. Wzorce „przedsiębiorczości” zniszczyły mózgi wielu ludzi w świecie Java EE. proszę nie powtarzać błędu w krainie .NET.

Klasy DTO służą do serializacji / deserializacji danych z różnych źródeł. Jeśli chcesz dokonać deserializacji obiektu ze źródła, nie ma znaczenia, jakie to źródło zewnętrzne: usługa, plik, baza danych itp., Możesz chcieć skorzystać tylko z niektórych jego części, ale chcesz w łatwy sposób zserializować dane do postaci obiekt. następnie skopiujesz te dane do XModel, którego chcesz użyć. Serializator to piękna technologia do ładowania obiektów DTO. Dlaczego? potrzebujesz tylko jednej funkcji do załadowania (deserializacji) obiektu.

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

Nawet nie nazywaj ich DTO. Nazywają się Modele .... Okres. Modele nigdy nie zachowują się. Nie wiem, kto wymyślił ten głupi termin DTO, ale to chyba wszystko .NET to wszystko, co mogę wymyślić. Pomyśl o widokach modeli w MVC, o tym samym dam **, modele są używane do przesyłania stanu między warstwami po stronie serwera lub w okresie przewodowym, wszystkie są modelami. Właściwości z danymi. Są to modele, które przekazujesz przez drut. Modele, modele Modele. Otóż ​​to.

Chciałbym, żeby głupi termin DTO odszedł od naszego słownictwa.