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

Question

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

Что вы делаете, это форма «жирного контроллера». В наши дни разработка программного обеспечения направлена ​​на тонкие контроллеры.

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

Отъезд "Domain-Driven Design Quickly." Эта бесплатная электронная книга представляет собой сжатое введение в концепцию, охватываемую важной книгой Эрика Эванса «Проект, управляемый доменами».

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

Answer 4

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

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