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?

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

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

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.

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.

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.