Что такое сущность программы

При моделировании такого понятия предметно-ориентированного проектирования как сущность могут возникнуть некоторые сложности, обусловленные бизнес-требованиями или технической частью. В частности, иногда возникает сложность с созданием объекта-сущности.

В данной статье описываются две такие проблемы, и рассматривается способ их решения. Так же статья подойдет как введение в проектирование сущностей. Для понимания материала понадобится базовое представление о предметно-ориентированном проектировании.

Итак, мы изучили предметную область, сформировали единый язык, выделили ограниченные контексты и определились с требованиями [2]. Всё это выходит за рамки данной статьи, тут мы попробуем решить конкретные узкие проблемы:

1. Создание и обеспечение консистентности сложных объектов-сущностей.
2. Создание объектов-сущностей с генерацией идентификатора по автоинкрементному полю базы данных.

Введение

У нас есть клиент, который должен быть смоделирован как сущность (Entity) [2]. С точки зрения бизнеса у каждого клиента обязательно есть:

Что такое сущность в практической магии. Какова природа сущности, и какими они бывают.

• имя или наименование;
• организационная форма (физ. лицо, ИП, ООО, АО и т.д.);
• главный менеджер (один из менеджеров, закрепляется за клиентом);
• информация о фактическом адресе;
• информация о юридическом адресе.

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

namespace Domain; final class Client

Целый ряд свойств мы опустили, для упрощения примера, реальный класс может быть значительно больше.

Полученная модель анемичная, перегружена ничего не значащими сеттерами вместо методов описывающих поведение соответствующее бизнес-требованиям. В любой момент, при таком подходе, можно создать объект в неконсистентном состоянии или нарушить бизнес-логику, установив один из параметров например так.

$client = new Client(); // В данный момент клиент у нас уже находится в не консистентном состоянии // Если мы хотим запросить его идентификатор, то получим ошибку, т.к. он ещё не установлен $client->getId(); // Или мы можем сохранить (попытаться) не валидного клиента, у которого не установлены обязательные свойства $repository->save($client);

Создание и обеспечение консистентности сложных объектов-сущностей.

Для начала попробуем решить проблему консистентности. Для этого уберем из класса сеттеры, а все обязательные параметры будем запрашивать в конструкторе [4]. Таким образом, объект будет всегда валиден, может использоваться сразу после создания и обеспечивается полноценная инкапсуляция предотвращающая возможность приведения клиента в неконсистентное состояние. Теперь наш класс выглядит следующим образом.

namespace Domain; final class Client

Проблему мы решили, но получилось не слишком изящно. 8 параметров у конструктора, и это не предел. Конечно, далеко не каждая сущность требует так много обязательных параметров, это, пожалуй, не совсем рядовая ситуация, но и не необычная.

Вся суть программирования за 15 минут…

Что можно с этим сделать? Простое и очевидное решение — сгруппировать логически связанные параметры в объектах-значениях (Value Object) [3].

namespace Domain; final class Address
namespace Domain; final class Client

Выглядит гораздо лучше, но параметров всё ещё довольно много, особенно это не удобно, если часть из них скалярные. Решение — шаблон Строитель (Builder) [5].

namespace Application; interface ClientBuilder
$client = $builder->setId($id) ->setName($name) ->setGeneralManagerId($generalManager) ->setCorporateForm($corporateForm) ->setAddress($address) ->buildClient();

Таким образом, моделируемая сущность всегда находится в консистентном состоянии и при этом может быть гибко и понятно построена, не зависимо от сложности создаваемого объекта и количества параметров.

Создание объектов-сущностей с генерацией идентификатора по автоинкрементному полю базы данных.

У проектируемого класса обязательно должен быть уникальный идентификатор, т.к. основной отличительной чертой сущностей является индивидуальность. Объект может значительно изменяться с течением времени, так что ни одно из его свойств не будет равным тому, что было вначале. В то же время все или большинство свойств объекта могут совпадать со свойствами другого объекта, но это будут разные объекты. Именно уникальный идентификатор дает возможность различать каждый объект не зависимо от его текущего состояния [1].

Существуют различные способы формирования идентификаторов, такие как пользовательский ввод, генерация в приложении по какому-либо алгоритму, может генерироваться базой данных.

Cгенерировать, например, UUID или запросить у базы данных очередное значение последовательности не составляет никаких трудностей. Но иногда возникает необходимость работать с уже существующей структурой БД, в которой таблица хранящая соответствующие данные имеет для идентификатора автоинкрементное поле.

В таком случае крайне затруднительно и ненадежно получать очередной уникальный идентификатор без сохранения сущности, а значит невозможно создать объект в полностью консистентном состоянии.

И снова нам поможет в этом шаблон Строитель, который мы можем реализовать следующим образом.

namespace Infrastructure; final class MySqlClientBuilder implements ClientBuilder < private $connection; public function __construct(Connection $connection); public function buildClient() < $this->connection ->insert(‘clients_table’, [ $this->name, $this->corporateForm, $this->generalManager->getId(), $this->address ]); $id = $this->connection->lastInsertId(); return new Client( $id, $this->name, $this->corporateForm, $this->generalManager, $this->address ); > >

Таким образом мы сначала добавляем соответствующую запись в базу данных, после чего получаем её идентификатор и создаем объект. Клиенту об этом знать не обязательно и при изменении способа хранения или генерации идентификаторов вам понадобится только заменить реализацию Строителя в вашем контейнере зависимостей.

$builder = $container->get(ClientBuilder::class); $client = $builder->setId($id) ->setName($name) ->setGeneralManagerId($generalManager) ->setCorporateForm($corporateForm) ->setAddress($address) ->buildClient(); $repository->save($client); $client->getId();

Благодарю за внимание!

P.S.:

Прошу не судить слишком строго, «чукча не писатель, чукча читатель». Для более опытных разработчиков описываемые вещи могут показаться банальными, я же к описанному пришел не сразу, но когда применил описанный подход, он зарекомендовал себя отлично.

Опыт разработки у меня относительно не большой — четыре года, DDD применял пока только на одном проекте.

Буду благодарен за отзывы и конструктивные замечания.

Ссылки:

1. Эванс Э., «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем.»
2. Вернон В., «Реализация методов предметно-ориентированного проектирования.»
3. М. Фаулер, Value Object
4. М. Фаулер, Constructor Initialization
5. Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидс, «Приёмы объектно-ориентированного проектирования. Паттерны проектирования.»

• domain-driven design
• design patterns
• anemic domain model
• rich domain model
• code complete
• mysql
• php
• ооп

Источник: habr.com

Что такое сущность в java?

Сущности в Java это простой объект, не обремененный, какими либо логическими обязательствами, хранящий и представляющий свои данные для других объектов. Не все объекты в Java могут быть сущностями, их отличительная черта в том, что их можно сериализовать и десериализовать.

1 эксперт согласен

подтверждает

Аргументировано

Показать ещё 1 комментарий

Программист, переводчик, педагог · 3 июн 2022

Если имеется в виду то, что по-английски зовётся Entity, — то это Java Bean, не использующий сложную логику для работы со своими свойствами. То есть POJO (Plain Old Java Object), который вообще ничего в пределе не делает: значения свойств хранятся в полях, из методов, кроме методов доступа к свойствам, — только equals() да hashCode() (они 1) должны быть определены и 2). Читать далее

Источник: yandex.ru

Entity (сущности) — зачем они нужны?

Всем добрый вечер. В ходе одного обучающего проекта наткнулся на необходимость использовать Entity (сущность). В данном случае, существует 3 класса, наследуемые друг от друга: Entity.java:

От него наследуется NamedEntity:
Отслеживать
4,286 1 1 золотой знак 19 19 серебряных знаков 35 35 бронзовых знаков
задан 28 июл 2017 в 19:31
Вячеслав Чернышов Вячеслав Чернышов
2,645 2 2 золотых знака 17 17 серебряных знаков 42 42 бронзовых знака

Да можем мы обойтись без них. Просто с ними понятнее структура и назначение каждого класса, если мы хотим добавить например адрес пользователя, то будеи наследоваться от BaseEntity, если допустим хотим добавить домашнее животно е которого есть кличка, то воспользуемся NamedEntity. + каждое из описаний не повторяет реализацию методов. DRY принцип. Кроме того мы видим иерархичность.

Так же это нам дает использовать общие методы работы на каждом из уровней иерархии классов. Гипкость в добавлении новых сущностей. Писать можно вечно об этом.

28 июл 2017 в 19:46

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Решить каким образом использовать сущности и использовать ли их вообще поможет понимание следующей модели представления даннных.

Когда мы говорим о сущностях в абстрактном смысле мы всегда в том или ином виде подразумеваем использование какой-либо модели данных. В частности, в программировании применяется EER-модель (Enhanced Entity-Relationship model). Расширенная модель включает все концепции ER-модели (entity-relationship model) и дополнительно включает понятия подкласса, суперкласса и относящиеся к ним понятия специализации, обобщения и категоризации. Далее рассмотрим базовую ER-модель.

«Набор данных, обычно относящихся к какой-либо предметной области или тематической области, и структурированных таким образом, чтобы обеспечить установление отношений между отдельными элементами данных в соответствии с различными потребностями пользователей.» G. Knott сущность-связь» основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным для нас является тот факт, что из модели «сущность-связь» могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.

Сущность фактически представляет из себя множество атрибутов, которые описывают свойства всех членов данного набора сущностей. Например, как у вас в коде. Есть базовая сущность BaseEntity , именованная сущность NamedEntity и конкретная User (пользователь). Таким образом сущность — это объект, который может быть идентифицирован неким способом, отличающим его от других объектов.

Преимущества использования ER-модели

• Высокая гибкость. Обеспечивают: модульность, что позволяет переиспользовать код следуя принципу DRY; простоту рефакторинга
• Местная автономия. В каждой отдельной части программы можно работать только с нужными нам сущностями.
• Простота понимания. За счет семантического моделирования данных, при котором отдельная сущность опирается на смысл этих данных. Любую модель легко изобразить в виде диаграммы.
• Наличие и простота визуализации. Нотация П. Чена, Crow’s Foot, UML, DFD, IDEF0 и IDEF1x, нотация Мартина, нотация Бахмана и др.

Недостатки использования ER-модели

• Сложность. Модель предназначена для высокого уровня абстракции. Увеличивается объем и сложность кодирования. Вам пришлось создать 3 класса со своими полями и методами, хотя можно было бы их оформить в одном классе. Кроме того разработчикам достаточно сложно хранить всю иерархию классов в голове.
• Безопасность. Трудно контролировать уровни доступности атрибутов сущности.
• Трудно поддерживать целостность. Такая модель чувствительна к изменению атрбутов.

Источник: ru.stackoverflow.com