оо вопрос - смешивание логики контроллера и бизнес логики

Question

Я не уверен, что использую «стандартные» термины, но это основной вопрос ОО, который я пытаюсь решить.

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

В пользовательском объекте есть два набора логики.

1. Логика "контроллера", которая решает, что и когда нужно сделать.
2. Фактическая бизнес-логика, которая делает то, что должно быть сделано (например, элемент управления, который выполняет математическую операцию и возвращает результаты и т. Д.).

Мой вопрос заключается в том, позволяет ли ОО-архитектура объединять их в одном объекте? Или рекомендуется разделить их на объект «контроллер» и объект «бизнес-логика»? Есть ли шаблон дизайна, к которому я должен обратиться для этого?

В настоящее время я начал собирать их в один объект. Этот объект имеет метод «start», который содержит логику контроллера. Затем этот метод при необходимости вызывает другие методы объекта и в конечном итоге возвращает результаты вызывающему объекту.

Answer 1

То, что вы делаете, является формой архитектуры "жирного контроллера". В наши дни разработка программного обеспечения имеет тенденцию к созданию тонких контроллеров.

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

Проверьте " Дизайн, управляемый доменом Быстро ." Эта бесплатная электронная книга представляет собой сжатое введение в концепции, описанные в важной книге Эрика Эванса «Проектирование на основе предметной области».

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

Answer 2

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

Answer 3

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

И ваш пользовательский интерфейс Windows Forms, и ваш веб-интерфейс будут вызывать одни и те же классы и методы. Таким образом, единственное различие заключается в том, как каждый заполняет пользовательский интерфейс и взаимодействует с другими уровнями.

Answer 4

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

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