Что такое классы управления?

Question

Я пытаюсь понять, как классифицировать классы как классы границы/управления/сущности. Я могу понять классы границ и сущностей, хотя мое понимание может быть неэффективным. Граница - это классы, которые взаимодействуют с пользователем. Таким образом, классы, используемые для пользовательского интерфейса, будут граничными классами. Класс Entity обрабатывает данные. Таким образом, объекты, которые я использую на диаграмме ER, будут классами сущностей. Но я ничего не понимаю, почему используется объект управления. Говорят, что объект управления используется для инкапсуляции функциональных возможностей домена. Что делать, если классы управления не используются. Можете ли вы объяснить мне пример. Я нашел некоторое объяснение, но я все еще запутался. Почему граница не должна взаимодействовать напрямую с сущностью? Существуют также классы, которые не являются границей/контролем/сущностью. Кто они такие?

Answer 1

• Граничная взаимодействуют с актерами (например, пользователей).

• Объект классы представляют данные.

• управления посредничает между границей и объектами (например, выполняет операцию на лиц)

Источник: http://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm

Answer 2

Классы управления содержат бизнес-логику. Это самая важная часть системы. Хотя граница просто контролирует, является ли текст зеленым или синим (в основном), и сущности контролируют, хранятся ли данные в текстовых файлах или базах данных (также очень в основном), классы управления выполняют всю бизнес-логику. Что изменить в сущности, когда граница посылает событиям мыши/клавиатуры на какой-нибудь стих, что показывать из объектов на границе.

Answer 3

фон

подход Entity/Boundary/Контроль был введен Ivar Jacobson в 1992 году как часть его использование случае приводимого метода Objectory развития.

В то время Якобсон использовал терминологию Entity/Interface/Control. Странная круговая нотация, которую вы можете найти в связи с ЕЦБ, уже использовалась в его книгах в 1992 году и в 1994 году. Кстати, прецедент его методов был интегрирован в UML, и его процесс разработки был объединен в RUP, когда Rational приобрела Objectory.

Идея его метода заключалась в принятии очень логичного и формального и дедуктивного подхода к анализу и дизайну. Он начинается с определения требований по поведению систем с использованием случаев использования. Каждая ссылка прецедента на внешний мир затем будет представлена ​​как объект интерфейса, ответственный за инкапсуляцию полностью пользовательского интерфейса.

Каждый случай использования будет представлен в виде одного или нескольких объектов управления:

объекта управления: Объект, который инкапсулирует функциональность одного или нескольких случаев использования - I.Jacobson в Преимущество объекта, ACM Press, 1994

Наконец, бизнес-объекты, управляемые системой, могут быть частично выведены из вариантов использования и во время анализа.

Дополнительная информация были введены

В фундаменты по Iconix process в 1999 году как часть книги «Use Case Driven моделирования объектов с UML» Розенбергом & Стефана. Некоторые дополнительные robustness constraints были введены, безусловно, для улучшения разделения проблем. Например, прямая связь между сущностью и границей запрещена. Все должно быть направлено через объекты управления:

объекты управления (которые мы обычно называем контроллеры, потому что они часто не являются реальными объектами), служит в качестве «клея» между граничными объектами и объектами объекта - D. Розенберг, в связанной статье DDJ.

Они добавляют рекомендации, чтобы прояснить цели:

Обе граничные объекты и объекты сущности являются существительными и контроллеры глаголы.

Заключение

Так принцип, что объект управления представляет собой бизнес-логику, предлагаемые прецедентами, взаимодействуя с одной стороны, с границами, а с другой стороны с сущностями. Объекты управления не могут быть вызваны/доступны непосредственно внешним миром.

Если вы хотите избежать объектов управления, у вас будут граничные объекты с методами, соответствующими глаголам/функциям/прецедентам, которые ваша система должна предоставлять. Это не было бы в соответствии с современным ЕЦБ, но было бы совершенно справедливо в соответствии с первоначальным подходом Джекобсона. Тем не менее ваша граница больше не будет соответствовать дизайну single responsibility principleSOLID.