У чому різниця між об’єктами домену, POCO та сутностями?


83

У мене склалося враження, що всі вони в основному однакові. Чи об’єкти моделі теж однакові?

Зараз у своїй архітектурі я маю:

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
    }

}

Отже , які з перерахованих вище класів POCO, Domain Object, Model object, entity?

Відповіді:


117

Мої (нестандартні) непрофесійні визначення

  • POCO- Звичайний старий об'єкт% Insert_Your_Language%. Тип без логіки. Він просто зберігає дані в пам'яті. Зазвичай ви бачите в ньому лише автоматичні властивості, іноді поля та конструктори.
  • Domain objectекземпляр класу, пов’язаного з вашим доменом. Можливо, я б виключив будь-які супутникові або службові об’єкти з об’єкта домену, наприклад, у більшості випадків об’єкти домену не включають такі речі, як реєстрація, форматування, серіалізація, шифрування тощо - якщо ви спеціально не створюєте продукт для реєстрації, серіалізації, форматування чи шифрування відповідно. .
  • Model objectЯ думаю, це те саме, що Domain object. Люди, як правило, використовують це взаємозамінно (я можу помилятися)
  • Entity клас, який має id
  • Repositoryклас, який звертається до сховища даних з одного боку (наприклад, до бази даних, служби даних або ORM) та до служби, інтерфейсу користувача, бізнес-рівня або будь-якого іншого запитуючого органу. Зазвичай він приховує всі пов’язані з даними речі (наприклад, реплікацію, пул з'єднань, обмеження ключів, транзакції тощо) і спрощує простою роботу з даними
  • Serviceпрограмне забезпечення, яке надає певні функціональні можливості, як правило, через загальнодоступний API. Залежно від рівня, це може бути, наприклад, RESTful автономний контейнер або клас, який дозволяє знайти конкретний екземпляр необхідного типу.

Оригінальна відповідь

Це терміни, які в основному використовуються в (розподіленому) дизайні, керованому доменом. Вони не однакові. Термін модель Об'єкт може використовуватися як синонім об'єкта домену .

Об'єкти домену.Об'єкти з конкретної галузі, що представляють щось значуще для експерта з доменів. Об'єкти домену в основному представлені сутностями та об'єктами значення. Взагалі кажучи, більшість об'єктів, які живуть на рівні домену, вносять вклад у модель і є об'єктами домену.

Сутність. Об'єкт фундаментально визначається не його атрибутами, а ниткою безперервності та ідентичності. (Це означає, що він повинен мати ідентифікатор )

POCO.Простий об’єкт без складної логіки, зазвичай він має лише кілька властивостей і використовується разом з ORM або як об’єкт передачі даних

class Person- Сутність та POCO, екземпляром цього класу є Об’єкт домену
class PersonService- Служба
class PersonRepository- Сховище


4
Будь ласка, перегляньте мій зразок коду вище та повідомте мені, як ви застосовуєте ці умови.
jpshook

Хороша відповідь. Я був готовий відповісти на це, але це була б копія Вашої відповіді. Я можу додати, що крім об'єктів Entity та Value у вас також є події домену тощо. Усі об'єкти та елементи, що перебувають у шарі домену та вносять вклад у модель, є об'єктами домену.
Магнус Бакеус,

1
Якщо POCO не потрібно ідентифікувати, як тоді його можна завантажити ORM. Це не логічно!
Паскаль

1
Чому ця відверто неправдива інформація є найбільш голосованою та прийнятою. POJO - НЕ тип, в якому немає логіки. Насправді Мартін Фаулер спеціально ввів термін POJO, щоб протиставити його Entity Beans ("ми вказували на багато переваг кодування ділової логіки в звичайні java-об'єкти, а не використовували Entity Beans"). martinfowler.com/bliki/POJO.html
КОРИСТУВАЧУ ПОТРІБНА ДОПОМОГА

1
Я перепрошую , якщо мій коментар був сильно сформульоване, але знову ж , ваш особистий досвід не має великого значення , коли фальшивомонетник терміна визначається POJO явно містять бізнес - логіку. Насправді він класифікує вашу практику за анемічною моделлю домену ( martinfowler.com/bliki/AnemicDomainModel.html ), яку він вважає анти-шаблоном, і рекомендує замість цього використовувати POJO. Чи є це анти-шаблон, поза сферою дії цього визначення, але очевидно одне: POJO не означає об'єкт без будь-якої бізнес-логіки.
ЦЕМУ КОРИСТУВАЧУ ПОТРІБНА ДОПОМОГА

19

в основному це зводиться до внутрішньої логіки

  1. Об’єкти домену мають внутрішню логіку домену для таких речей, як перевірка тощо.
  2. Модель в основному є легким об’єктом Домену, вони знають про дані, які вони мають, але насправді нічого не стосуються того, як вони будуть використовуватися
  3. Суб’єкти зберігають дані та мають певні внутрішні знання про те, звідки вони надійшли, і де вони будуть збережені, оновлені тощо
  4. POCO зберігає дані і може мати певні внутрішні знання про себе, такі як загальна вартість усіх предметів у колекції майна
  5. DTO - найпростіший елемент з усіх, він просто містить дані і не має логіки

Всі вони в основному використовуються для одного і того ж, просто наскільки розумними ви хочете, щоб вони були

відповідно до вашого зразка коду Клас Person буде об’єктом домену або моделлю, інші 2 - це служба та сховище. Об'єкти домену, Pocos, моделі, dtos тощо використовуються як повідомлення, що передаються від одного шару до наступного, клас послуг, такий як PersonService, є шаром у програмі і таким самим із класом сховища, як PersonRepository. для гарного огляду загляньте на http://bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.html, у цьому випадку мова йде про використання сутність даних, яка в основному є dto


18

Це скоріше конотація функції; об’єкт домену - це те, що є специфічним для вашої реалізації логіки і може бути більш складним, ніж простий POCO; сутність має конотацію, яка представляє щось (як правило, відносно середовища стійкості), а POCO - це лише швидкий ідентифікатор класу. Модель - це просто термін, який використовується для представлення об'єкта (зазвичай містить стан і зазвичай має справу з користувацьким інтерфейсом або БД).

Справа не в тому, що є якась функціональна різниця, це просто різні терміни, щоб більш точно описати щось. Як і різниця між гоночним автомобілем, вантажівкою та сімейним седаном. Всі вони є автомобілями, але кожен термін є більш описовим.


Я оновився, щоб включити зразок коду, чи можете ви прокоментувати? Я просто хочу переконатись, коли я задаю питання, чи використовую я правильні терміни.
jpshook,

11

У відповідях вище вже є хороші пояснення щодо Домену та Моделі.

У контексті бази даних-контекст сутність означає Елемент у моделі взаємозв'язку сутності ERD . (тобто рядок у таблиці)

У Microsoft-Dotnet-EntityFramework-World Entity розуміється Об'єкт, який можна завантажити з бази даних та зберегти в базі даних за допомогою контексту даних (бази). Зазвичай Сутність не може існувати без контексту даних (бази). (Unit-) Тестування ділової функціональності цих класів є складною.

Pocos (звичайні старі об'єкти загального виконання) можуть існувати без PersistenceFramework (EntityFramework або NHibernate), тому їх набагато легше перевірити.

Слово poco - це пристосування pojo (звичайний старий об'єкт Java), які були створені у світі Java з тієї ж причини.


в чому причина відсутності голосування? Питання було "Яка різниця між об’єктами домену, POCO та сутностями?" я пояснив різницю між Entity та Poco
k3b

"У відповідях вище вже є хороші пояснення щодо Домену та Моделі." Як я можу вибрати відповідь, яка залежить від інших відповідей, як дійсну?
jpshook

нп. В ретроспективі я повинен був просто прокоментувати, просячи вас надати повну відповідь. Наступного разу подумаю двічі.
jpshook

3

Об’єкт домену - це сутність на рівні домену вашої програми, наприклад. клас адреси. "Модель" означає те саме - сутність у "Моделі домену".

POCO (звичайний старий об'єкт CLR) - це об'єкт, який не має визначеної поведінки (методів) і містить лише дані (властивості). POCO, як правило, використовуються як DTO (об'єкти транспортування даних) для перенесення даних між шарами, а дані потім зазвичай використовуються для заповнення об'єкта / сутності домену.


Чи не може POCO бути суб'єктом? Я думав, що POCO можуть мати поведінку, але, напевно, не знають про наполегливість?
jpshook

@Developr Так, ваші моделі доменів / сутностей справді можуть бути POCO - це те, що відоме як "анемічна" модель домену - див. Martinfowler.com/bliki/AnemicDomainModel.html
MattDavey,

Як би ви вважали це анемічним? Як ви визначаєте "багатий об'єкт домену?" Якщо об’єкти домену не можуть взаємодіяти прямо чи опосередковано з базою даних, якою багатою функціональністю вони можуть володіти?
jpshook

@Developr Я б вважав модель домену, що складається з об'єктів POCO, анемічною, оскільки традиційно класи POCO не мають розширених функціональних можливостей, а лише дані. Дотримуючись принципу розділення турбот ( en.wikipedia.org/wiki/Separation_of_concerns ), об’єкт у моделі домену взагалі не повинен займатися доступом до бази даних (звідси популярний термін «постійність незнання»). Типом функціональності, яку повинна мати сутність в моделі домену, буде бізнес-логіка - вони повинні фіксувати та інкапсулювати логічні правила та робочі процеси проблеми / домену, який вони представляють.
MattDavey
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.