Что такое DCI и как он может соответствовать рельсам?
недавняя дискуссия с коллегой о различных подходах к проектированию и кодированию моделей в приложении Rails привела меня к DCI в контексте Rails.
тем не менее, я просто не могу обернуть голову вокруг всей этой концепции, даже после перехода этот пример приложения.
В настоящее время я склонен просто идти более или менее "книги" при написании приложения Rails.
Итак, есть несколько вещей Я хотел бы спросить ... --3-->
- Что такое DCI и каковы его преимущества при реализации вместе с MVC над простым старым MVC (и vanilla ActiveRecord в Rails) ?
- и как это может быть реализовано в Rails (или другими словами, что со всеми модулями) ?
редактировать
Я хотел бы еще больше расширить свой вопрос в контексте RoR-это еще один уровень абстракции между моделями и контроллеров в Rails рекомендуется? Насколько широко он распространен в приложениях различного масштаба?
4 ответов
DCI-это парадигма и, следовательно, гораздо больше, чем способ разработки приложения. Это способ думать о моделировании, а также структурировании кода. Одной из важных частей DCI является сохранение того, что такое система (модель домена) и что делает система (функциональность) отдельно. DCI-это не другой подход к решению той же проблемы, что и MVC, поэтому на ваш первый вопрос нельзя ответить. Вы можете использовать MVC и DCI одновременно, что не является совпадением, так как Trygve Renskaug является отцом и MVC, и DCI. Недавно он ответил аналогичный вопрос к этому в группе google "объект-композиция".
пример, с которым вы связались, нарушает некоторые из основных идей, таких как сохранение ролей в контекстах, и я не мог найти ни одного контекста, но это может быть связано с тем, что я потратил только короткое время на просмотр кода.
Я не знаю RoR себя, поэтому я не могу дать вам пример RoR, но если вы идете в fullOO вы найдите примеры, написанные на разных языках, включая Ruby и Marvin первый язык, предназначенный для DCI.
редактировать нет простого ответа на вопрос "Что такое DCI" DCI-это парадигма, так же, как ООП-это парадигма. Они оба имеют одни и те же корни, и ответ на вышеуказанный вопрос так же сложен, как ответ "что такое объектно-ориентированное программирование". Все еще сложнее из-за того, что DCI является объектно-ориентированным и ООП во всех основных ОО языки на самом деле ориентированы на класс, а не на объект. DCI нацелен на создание кода, где взаимодействие между объекты во время выполнения отображается в коде во время компиляции и в более общих чертах пытается mkae легче рассуждать о поведении во время выполнения от чтения кода. The сайт Я связался с выше, посвящен объяснению того, что такое DCI, а также перечисляет примеры на нескольких языках. Рубин, являясь одним из их!--3-->
редактировать здесь книги на ruby и DCI на этом пути. Автор довольно активен по объектной композиции и проницателен
в центре DCI это когнитивные инструменты, которые он предоставляет разработчику. Я не уверен, что вы видели все великие James Coplien/Trygve Reenskaug лекции, но я попытаюсь дистиллировать суть его для тех, кто новичок в концепциях. Речь идет о перемещении поведения системы из взаимодействующих объектов домена систем (сущностей данных или системы) и в объекты поведения (что делает система) в качестве граждан первого класса, которые опосредуют сотрудничество между объектами, вводя их с функциональностью в контексте варианта использования just-in-time.
подумайте BDD. Мы кодируем поведение не во многих объектах, таких как частицы функциональности, разбросанные по всем нашим объектам данных, которые сильно связаны со слоем персистентности, но внутри когезионных объектов, которые существуют исключительно для случая использования(истории) и которые вводят возможности и координируют взаимодействия этих немых объектов данных. Как прозрачные слои физического архитектура, медленно меняющиеся объекты данных не загружаются с быстро меняющейся реализацией функций, которые они несут вокруг все время. Скорее, Ruby предоставляет нам возможность легко вводить поведение в объекты во время выполнения, когда/если это необходимо только в контексте варианта использования.
в качестве примера в ROR, если у вас есть действие контроллера, участвующее в случае использования, в котором есть матрица вероятности событий, где большинство записей может быть вызвано только в небольшом проценте запросы, а затем создание экземпляра сети раздутых поведенческих тяжелых объектов со знанием выполнения каждого события для каждого возможного варианта использования данных не требуется. Кроме того, не нужно копаться в 18 файлах в моем текстовом редакторе, чтобы понять, как работает это взаимодействие, и иметь всю логику, чисто абстрагированную от шаблонов в интерфейсе, предоставляемом объектом контекста, также является определенным плюсом.
Что касается вашего вопроса о "другом" слое абстракции между контроллеры и модели в rails, я не уверен, какой другой из них вы имеете в виду. Несмотря Ни На Что, Да. Конечно. Не проблема. шаблоны проектирования и дядя Боб' твердый принципы-это в значительной степени общепринятые лучшие практики в дизайне OO. Оба эти фактора в значительной степени поощряют слабо связанные абстракции между политикой и ее осуществлением. Они оба помогают избежать катострофических свалок мозга Римской империи разрушительной величины, потому что они обеспечивают общую основу все понимают. DCI, для меня, обеспечивает тот же тип когнитивной структуры, но для облегчения понимания системы и эффективного решения, и это Святой Грааль для любого объектно-ориентированного дизайнера.
есть книга (в настоящее время выполняется) по использованию DCI в Ruby / Rails:Чистый Рубин. Я настоятельно рекомендую поместить себя в список уведомлений - я читал части этой книги, и это выглядит действительно хорошо.
DCI получает признание в мире Rails - за последние 3 месяца или около того было много интересных сообщений в блоге об этом.