Jaka jest różnica między obiektami domeny, POCO i encjami?


83

Miałem wrażenie, że wszystkie są w zasadzie takie same. Czy obiekty modelu też są takie same?

W tej chwili w mojej architekturze mam:

class Person 
{

    public string PersonId;        
    public string Name;
    public string Email;

    public static bool IsValidName() { /* logic here */ }
    public static bool IsValidEmail() { /* logic here */ }
}


class PersonService
{
    private PersonRepository pRepository;

    PersonService()
    {
        pRepository = new PersonRepository();
    }

    public bool IsExistingEmail(string email)
    {
        //calls repo method to see if email is in db
    }


    public Person GetPerson(email)
    {
        return pRepository.Get(email);
    }


    public void SavePerson(Person p)
    {
        if (Person.IsValidEmail(p.Email) && !IsExistingEmail(p.Email)
        {
            pRepository.Save(p);
        }
    }

}


class PersonRepository
{
    public void Save(Person p)
    {
        //save to db
    }

    public Person Get(string email)
    {
        //get from db
    }

    public bool IsExistingEmail(string email)
    {
        //see if email in db
    }

}

Więc który z tych klas są POCO, Domain Object, Model object, entity?

Odpowiedzi:


117

Moje (niestandardowe) definicje laika

  • POCO- Zwykły, stary obiekt% Insert_Your_Language%. Typ bez logiki. Po prostu przechowuje dane w pamięci. Zwykle widzisz w nim tylko właściwości automatyczne, czasami pola i konstruktory.
  • Domain objectinstancja klasy, która jest powiązana z Twoją domeną. Prawdopodobnie wykluczyłbym wszelkie obiekty satelitarne lub użytkowe z obiektu domeny, np. W większości przypadków obiekty domeny nie obejmują takich rzeczy, jak logowanie, formatowanie, serializacja, szyfrowanie itp. - chyba że tworzysz produkt specjalnie do logowania, serializacji, formatowania lub szyfrowania .
  • Model objectMyślę, że to to samo co Domain object. Ludzie zwykle używają tego zamiennie (mogę się mylić)
  • Entity klasa, która ma id
  • Repositoryklasa, która mówi do magazynu danych z jednej strony (np. baza danych, usługa danych lub ORM) oraz do usługi, interfejsu użytkownika, warstwy biznesowej lub innego podmiotu żądającego. Zwykle ukrywa wszystkie rzeczy związane z danymi (takie jak replikacja, pule połączeń, ograniczenia klucza, transakcje itp.) I ułatwia pracę z danymi
  • Serviceoprogramowanie, które zapewnia pewną funkcjonalność zwykle za pośrednictwem publicznego interfejsu API. W zależności od warstwy może to być na przykład samodzielny kontener RESTful lub klasa, która pozwala znaleźć konkretną instancję wymaganego typu.

Oryginalna odpowiedź

Są to terminy, które są powszechnie używane w (rozproszonym) projektowaniu opartym na domenie. One nie są takie same. Termin model Object może być używany jako synonim obiektu domeny .

Obiekty domeny. Obiekty z obszaru biznesowego, które reprezentują coś znaczącego dla eksperta dziedzinowego. Obiekty domeny są najczęściej reprezentowane przez encje i obiekty wartości. Mówiąc ogólnie, większość obiektów znajdujących się w warstwie domeny ma swój udział w modelu i jest obiektami domeny.

Jednostka. Przedmiot zasadniczo definiowany nie przez jego atrybuty, ale przez nić ciągłości i tożsamości. (Co oznacza, że musi mieć Id )

POCO. Prosty obiekt bez skomplikowanej logiki, zwykle ma tylko kilka właściwości i jest używany z ORM lub jako obiekt transferu danych

class Person- Entity i POCO, instancją tej klasy jest Domain Object
class PersonService- Service
class PersonRepository- Repository


4
Zobacz mój przykładowy kod powyżej i daj mi znać, jak zastosujesz warunki.
jpshook

Dobra odpowiedź. Byłem gotowy odpowiedzieć na to pytanie, ale to byłaby kopia twojej odpowiedzi. Mogę dodać, że oprócz obiektów Entity i Value masz również Domain Events, itp. Wszystkie obiekty i żyją w warstwie Domain i współtworzą model są obiektami Domain.
Magnus Backeus

1
Jeśli POCO nie wymaga identyfikacji, w jaki sposób można go załadować przez ORM. To nielogiczne!
Pascal

1
Dlaczego ta rażąco fałszywa informacja jest najbardziej popierana i akceptowana. POJO NIE jest typem bez logiki. W rzeczywistości Martin Fowler specjalnie ukuł termin POJO, aby odróżnić go od Entity Beans („wskazywaliśmy na wiele korzyści płynących z kodowania logiki biznesowej w zwykłych obiektach Java zamiast używania Entity Beans”). martinfowler.com/bliki/POJO.html
TEN UŻYTKOWNIK POTRZEBUJE POMOCY

1
Przykro mi, jeśli mój komentarz był mocno sformułowany, ale znowu, twoje osobiste doświadczenie nie ma większego znaczenia, gdy twórca terminu zdefiniował POJO, aby wyraźnie zawierał logikę biznesową. W rzeczywistości zaklasyfikowałby twoją praktykę w modelu domeny anemicznej ( martinfowler.com/bliki/AnemicDomainModel.html ), który uważa za anty-wzorzec, i zaleca zamiast tego użycie POJO. To, czy jest to anty-wzorzec, jest poza zakresem tej definicji, ale jedno jest jasne: POJO nie oznacza obiektu bez logiki biznesowej.
TEN UŻYTKOWNIK POTRZEBUJE POMOCY

19

w zasadzie sprowadza się do wewnętrznej logiki

  1. Obiekty domeny mają wewnętrzną logikę domeny do takich rzeczy, jak walidacja itp.
  2. Model jest w zasadzie lekkim obiektem domeny, wiedzą o danych, które przechowują, ale tak naprawdę nie mają nic o tym, jak będzie używany
  3. Podmioty przechowują dane i mają wewnętrzną wiedzę o tym, skąd pochodzą, gdzie będą zapisywane, aktualizowane itp
  4. POCO przechowuje dane i może mieć wewnętrzną wiedzę o sobie, np. Jaka jest całkowita wartość wszystkich elementów w kolekcji nieruchomości
  5. DTO jest najprostszą pozycją ze wszystkich, po prostu przechowuje dane i nie ma logiki

Wszystkie są zasadniczo używane do tego samego, po prostu tak inteligentne chcesz, aby były

zgodnie z przykładowym kodem Klasa Person byłaby obiektem domeny lub modelem, pozostałe 2 to usługa i repozytorium. Obiekty domeny, Pocos, modele, dtos itp. Są używane jak wiadomości, przekazywane z jednej warstwy do drugiej, klasa usług, taka jak PersonService, jest warstwą w aplikacji i to samo z klasą Repository, taką jak PersonRepository. aby uzyskać dobry przegląd, spójrz na http://bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.html w tym przypadku chodzi o używanie jednostka danych, która jest w zasadzie dto


18

To bardziej konotacja funkcji; obiekt domeny to coś, co jest specyficzne dla twojej implementacji logiki i może być bardziej złożone niż proste POCO; byt ma konotację do reprezentowania czegoś (zwykle w odniesieniu do medium trwałego), a POCO jest tylko szybkim identyfikatorem klasy. Model to po prostu termin używany do reprezentowania obiektu (zwykle zawiera stan i zwykle dotyczy interfejsu użytkownika lub bazy danych).

Nie chodzi o to, że istnieje jakaś różnica funkcjonalna, są to po prostu różne terminy, które dokładniej coś opisują. Jak różnica między samochodem wyścigowym, ciężarówką i rodzinnym sedanem. Wszystkie są samochodami, ale każdy termin jest bardziej opisowy.


Zaktualizowałem, dodając przykładowy kod, czy możesz skomentować? Chcę się tylko upewnić, że zadając pytania, używam właściwych terminów.
jpshook

11

W powyższych odpowiedziach są już dobre wyjaśnienia dziedziny i modelu.

W przypadku encji kontekstu bazy danych oznacza pozycję w modelu relacji encji ERD . (tj. wiersz w tabeli)

W Microsoft-Dotnet-EntityFramework-World Entity oznacza obiekt, który można załadować z bazy danych i zapisać w niej przy użyciu kontekstu danych (bazowego). Zwykle jednostka nie może istnieć bez kontekstu danych (podstawowego). (Jednostka-) Testowanie funkcjonalności biznesowej tych klas jest trudne.

Pocos (zwykłe, stare, pospolite obiekty Runtime) mogą istnieć bez PersistenceFramework (EntityFramework lub NHibernate), dzięki czemu są znacznie łatwiejsze do przetestowania.

Słowo poco jest adaptacją pojo (zwykły stary obiekt Java), które zostały utworzone w świecie Java z tego samego powodu.


jaki jest powód odrzucenia głosów? Pytanie brzmiało: „Jaka jest różnica między obiektami domeny, POCO i encjami?” wyjaśniłem różnicę między Entity a Poco
k3b

„W powyższych odpowiedziach są już dobre wyjaśnienia dziedziny i modelu”. Jak mogę wybrać odpowiedź, która zależy od innych odpowiedzi, jako prawidłową odpowiedź?
jpshook

np. Z perspektywy czasu powinienem był po prostu skomentować, prosząc o udzielenie pełnej odpowiedzi. Następnym razem pomyślę 2x.
jpshook

3

Obiekt domeny to jednostka w warstwie domeny Twojej aplikacji, np. klasa adresu. „Model” oznacza to samo - podmiot w „Modelu Domeny”.

POCO (zwykły stary obiekt CLR) to obiekt, który nie ma zdefiniowanego zachowania (metod) i zawiera tylko dane (właściwości). POCO są zwykle używane jako DTO (obiekty transportu danych) do przenoszenia danych między warstwami, a dane są następnie powszechnie używane do zapełniania obiektu / jednostki domeny.


Czy POCO nie może być bytem? Myślałem, że POCO mogą zachowywać się, ale muszą być wytrwałymi ignorantami?
jpshook

@Developr Tak, twoje modele / podmioty domeny mogą rzeczywiście należeć do POCO - jest to tzw. „Anemiczny” model domeny - patrz martinfowler.com/bliki/AnemicDomainModel.html
MattDavey

Jak oceniasz tę anemię? Jak definiuje się „bogaty obiekt domeny”? Jeśli obiekty domeny nie mogą bezpośrednio lub pośrednio współdziałać z bazą danych, jaką bogatą funkcjonalność mogą mieć?
jpshook

@Developr Uważam, że model domeny złożony z obiektów POCO jest anemiczny, ponieważ tradycyjnie klasy POCO nie mają żadnej bogatej funkcjonalności, tylko dane. Zgodnie z zasadą Separation of Concerns ( en.wikipedia.org/wiki/Separation_of_concerns ), obiekt w modelu domeny nie powinien w ogóle zajmować się dostępem do bazy danych (stąd popularny termin „trwałość ignorancji”). Rodzaj funkcjonalności, który jednostka powinna mieć w modelu domeny, to logika biznesowa - powinny one przechwytywać i hermetyzować reguły logiczne i przepływy pracy problemu / domeny, którą reprezentują.
MattDavey
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.