Что такое DCI и как он может соответствовать Rails?

Недавняя дискуссия с коллегой о различных подходах к разработке и кодированию моделей в приложении Rails привела меня через DCI в контексте Rails.

Однако я просто не могу обойти эту концепцию даже после перехода этого примера приложения.

В настоящее время я склонен к более или менее " по книге" при написании Rails приложение.

Итак, есть несколько вещей, которые я хотел бы задать -

Что такое DCI и каковы его преимущества при реализации вместе с MVC поверх простого старого MVC (и ванильного ActiveRecord в Rails)?
И как это можно реализовать в Rails (или, другими словами, что со всеми модулями)?

Edit

Я хотел бы еще больше расширить свой вопрос в контексте RoR - это еще один уровень абстракции между моделями и контроллерами в Rails? Насколько широко распространено это в приложениях различного масштаба?

Ответ 1

DCI - это парадигма и, следовательно, гораздо больше, чем способ разработки приложения. Это способ думать о моделировании, а также о структурировании кода. Одной из важных частей DCI является то, что система (модель домена) и что делает система (функциональность) отдельно. DCI - это не другой подход к решению той же проблемы, что и MVC, поэтому на ваш первый вопрос нельзя ответить. Вы можете использовать MVC и DCI одновременно, что не случайно, поскольку Trygve Renskaug является отцом MVC и DCI. Недавно он ответил на аналогичный вопрос этому объекту-композиции группы google.

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

Я не знаю RoR, но я не могу дать вам пример RoR, но если вы перейдете к fullOO, найду примеры, написанные на разных языках, включая Ruby и Marvin, первый язык, предназначенный для DCI.

РЕДАКТИРОВАТЬ Нет простого ответа на вопрос "Что такое DCI". DCI - это парадигма, так же как ООП - парадигма. Оба они имеют одинаковые корни, и ответ на вышеупомянутый вопрос столь же сложный, как и ответ "Что такое ориентированное на объект программирование". Все дело еще сложнее в том, что DCI объектно-ориентированный, а ООП во всех основных языках OO на самом деле ориентирован на классы, а не объектно-ориентирован. DCI нацелен на создание кода, в котором взаимодействие между объектами во время выполнения видимо в коде во время компиляции и в более общих терминах пытается облегчить рассуждение о времени выполнения программы при чтении кода. Сайт который я связал выше, посвящен объяснению того, что такое DCI, а также перечисляет примеры на нескольких языках. Ruby является одним из них

РЕДАКТИРОВАТЬ Там

Ответ 2

Для людей, которые задаются вопросом, что означает DCI.

DCI означает Data Context Interaction

Ответ 3

В основе DCI - это когнитивные инструменты, которые он предоставляет разработчику. Я не уверен, что вы видели лекции по всем великим James Coplien/Trygve Reenskaug, но я постараюсь переделать суть этого для любой, кто знаком с концепциями. Речь идет о перемещении системного поведения из взаимодействующих объектов домена (объектов данных или системы) и в объекты поведения (что делает система) в качестве граждан первого класса, которые опосредуют сотрудничество между объектами, введя их функциональность в контексте случая использования точно в срок.

Думайте BDD. Мы кодируем поведение не по многим объектам, как частица функциональности, распространяемая по всем нашим объектам данных, которые тесно связаны с уровнем персистентности, но внутри сплоченных объектов, которые существуют исключительно для использования (история) и которые вводят возможности в и координируют взаимодействия этих немых объектов данных. Подобно явным слоям физической архитектуры, медленно меняющиеся объекты данных не загружаются быстро меняющейся функцией реализации, которую они несут постоянно. Скорее, Ruby предоставляет нам возможность легко вводить поведение в объекты во время выполнения, когда/если это необходимо, только в контексте использования.

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

Что касается вашего вопроса о "другом" слое абстракции между контроллерами и моделями в рельсах, я не уверен, к какому другому относится ваше обращение. Независимо, да. Во всех смыслах. Нет проблем. Шаблоны проектирования и дядя Бобс SOLID принципы довольно много общепринятых лучших практик в разработке OO. Оба они настоятельно поддерживают слабосвязанные абстракции между политикой и реализацией. Они оба помогают избежать катастрофических отвалов мозга римской империи, разрушающих масштабы, потому что они обеспечивают общую основу, которую все понимают. DCI, для меня, обеспечивает тот же тип когнитивной структуры, но для того, чтобы сделать систему более понятной и эффективной, и это святой грааль для любого объектно-ориентированного дизайнера.

Ответ 4

Существует книга (в настоящее время) об использовании DCI в Ruby/Rails: Clean Ruby. Я настоятельно рекомендую включить себя в список уведомлений - я читал части этой книги, и это выглядит очень хорошо.

DCI получает признание в мире Rails - за последние 3 месяца было опубликовано несколько интересных сообщений в блоге.