zelenin писал(а):так вы объясните, чем вам примеры по ссылкам не угодили? вам кажется, что это не то или это ваша принципиальная позиция, что тот код надо скопипастить сюда?
Нет ни каких принципов тут нет. Не хотелось бы, чтобы сюда копипастили отрывки кода. Я хотел, чтобы весь код был в одном месте, одной "простыней" ,не копипаст, не ссылки.Реализация какого-нибудь простого функционала блога (вывод статьи и изменение статьи).Пусть содержится всего пару свойств для примера - title, text... Чтобы можно видеть общую картину не листая и не собирая все по кусочкам. Код классов в одном месте. Сокращенный вариант. Все.
Пусть с таким скудным функционалом организовывать такие архитектурные решение- излишество. Но для примера - самое оно.
Последний раз редактировалось magicoder 2016.07.25, 15:34, всего редактировалось 1 раз.
Разработка на yii2 или чистом php.| email: site4coder@gmail.com | skype: for-web1
zelenin писал(а):так вы объясните, чем вам примеры по ссылкам не угодили? вам кажется, что это не то или это ваша принципиальная позиция, что тот код надо скопипастить сюда?
Нет ни каких принципов тут. Не хотелось бы, чтобы сюда копипастили. Я хотел, чтобы весь код был в одном месте, одной "простыней" ,не копипаст, не ссылки. Чтобы можно видеть общую картину не листая и не собирая все по кусочкам. Код классов в одном месте. Сокращенный вариант. Все.
ну поехали по кругу. У Melodic целое предложение на битбакете на yii2, я уже в этой ветке кинул ссылку на классическое cargo приложение (на psr7/middleware фреймворке).
Если нужно, берите и копипастьте сюда простыней, чтобы вам было удобнее.
zelenin писал(а):
Если нужно, берите и копипастьте сюда простыней, чтобы вам было удобнее.
Странно, что Вы не понимаете ...
странно, что вы не понимаете.
Ну да ладно, наверное тут уже нужно не за спасибо, на сколько я понял...
на сколько я понял, вы просите скопипастить абстрактного меня сюда вам кода из других веток, вместо того, чтобы сделать это самому. Сделайте это сами за спасибо.
magicoder писал(а):Так зачем тогда сюда писать, если нет желания помочь, а только умничать какие мы все такие не земные?
именно за тем, чтобы понять зачем вы сюда пишете, если нет желания самому скопипастить. Вы без рук что ли? ctrl+c/ctrl+v не работает? Чем вам помочь еще в рамках этой ветки? Денег вы не просите, научить чему-то не просите. Вы просите только скопипастить - а вам инфы дали много больше. Сиди и изучай.
Вы же просите одной простыней, потому что не понимаете для чего оно вообще нужно и что это такое. Поэтому же не понимаете, что полнейшие примеры вам уже дали, а отличия в yii2 варианте будут минимальнейшие в 10% кода с уменьшением при росте проекта. Причем именно эти отличия уже Дмитрий конкретно описал кусками кода, уложившись в 5 строк. Вы просите лишь потому, что считаете, что yii2 вариант будет содержать какие-то свои особенности, знание которых вам поможет при написании приложения со слоистой архитектурой, но зачем оно вам, какие проблемы будет решать, вы не понимаете.
Начните уже программировать, а не просить не нужных никому вещей.
zelenin писал(а):
Начните уже программировать, а не просить не нужных никому вещей.
Ну раз ни кому не нужно ,просить не буду. Вы вот советуете на форуме создавать сервисы, чтобы минимизировать код в модели и контроллере. Это то нужно точно народу. Будет куда ссылку дать ,если выложите тут пример конечно.
Разработка на yii2 или чистом php.| email: site4coder@gmail.com | skype: for-web1
magicoder писал(а):Вы вот советуете на форуме создавать сервисы, чтобы минимизировать код в модели и контроллере. Это то нужно точно народу. Будет куда ссылку дать ,если выложите тут пример конечно.
Объекты просто с полями, но без функциональных методов - это структуры данных, DTO, используемые для переноса даных вместо ассоциативных массивов. Это у нас сами команды UserSignupCommand для передачи кучи полей одной пачкой из контроллера.
Полноценные объекты с id, внутренним миром (полями) и управляющими всем этим методами - это сущности. Это у нас User, Product, Post, Company. В Yii2 их обычно называют моделями.
Вспомогательные объекты с дополнительными данными для сущностей - это объекты-значения. Это тот же Address внутри Company.
Все остальные объекты без личной жизни, но с методами, выполняющими какие-то операции - это сервисы. Это у нас абсолютно всё остальное, что что-то делает: хешеры, калькуляторы, менеджеры, хэндлеры команд, нотификаторы, мэйлеры...
Это и есть минимальная номенклатура.
magicoder писал(а):Вы вот советуете на форуме создавать сервисы, чтобы минимизировать код в модели и контроллере.
UserService или хэндлеры команд - сервисы прикладного уровня. В них мы выносим код из контроллеров. В контроллере остаётся только загрузка формы и вызов сервиса.
Хэшеры, калькуляторы и прочее вспомогательное - сервисы домена. В них перекочёвывает посторонний код из моделей.
Последний раз редактировалось ElisDN 2016.07.25, 20:30, всего редактировалось 12 раз.
Позвольте добавить немного своих мыслей, своими словами.
Слоистая архитектура - архитектура приложения разбитая на разные слои, с разделением отвественности.
Графически такую архитектуру представляют перевернутой пирамидой, так удобно отделить ответственность сверху вниз,
где каждый слой обладает информацией о том, как обратиться к слою, расположенному непосредственно под ним и никак наоборот.
Хотя есть вариант "луковой", смысл в ней в принципе если присмотреться - тот же.
Если я не ошибаюсь, началось все с 3-х слойной системы: User Interface (UI) -> Business Logic (BL) -> Data Access Layer (DAL).
Со временем:
- BL, был разделен на два Application Layer и Domain Model, т.к. это ядро любой системы и нужно было чуть облегчить
- DAL стали называть Infrastructure Layer, т.к. система может работать с данными из разных частей инфраструктуры (БД, файлы, сторонние серверы, факсы, и т.д.).
ООП - процесс моделирования, проектирования задачи (приложения) в виде объектов.
Объекты тем самым делятся на два типа:
1. Объекты - вещи. Объекты вещи делятся на два подтипа:
1.1. Сущности - вещи имеют состояние (свойства объекта) и поведения меняющие состояние (методы объекта).
Такие вещи имеют жизненный цикл, т.е. способность менять свое состояние. Дабы разделять две вещи одного класса с одинаковым состоянием им необходим идентификатор, уникальное свойство (или группа свойств).
1.2. Объект-Значение - модель какого-то сложного значения, какая-то вещь не имеющая жизненный цикл, не неизменным состоянием. Такие модели могут иметь поведения, но в отличии от сущности, они меняют не свое поведение а порождают другие данные.
Это очень важно помнить - об неизменности, потому что такие объекты в одинаковом состоянии считают равными,
и один экземпляр объекта может быть присвоен разным сущностям, меняя объект-значение одной сущности, это не должно влиять на другую.
Примеры:
В разных контекстах (частях приложения) или в разных приложениях, одни и те же вещи могут быть и сущностями и значениями.
Address, в контексте системы городского учета адресов:
Это сущность, его жизненный цикл: регистрация в системе, застройка здания на нем, удаление из системы.
Address, в контексте пользователей системы:
У него нет жизненного цикла, это всего лишь комплексное значение, состоящее из улицы, номера дома и т.д.
Несколько пользователей могут иметь один и то же адрес, и он может (должен) быть представлен одним объектом,
что сделает приложение менее ресурсопотребляемым.
2. Сервисы - объект модель како-либо процесса. Сервисы не имеет состояния, его ответственность изменить состояние объектов-данных, вычислить что-либо, и т.д..
Но очень часто "сервисами" называют только классы из "сервисного слоя" (Service Layer).
Термин появившийся, ИМХО, по ошибке, при неверном толкования MVC, не хватало чего то между "C" и "M",
придумали "сервисный слой", и стали туда переносить часть "C".
На самом деле сервисы бывают на любом слое, ну ведь логично, что процессы они везде есть, все зависит от отвественности что на него поставлена. Репозитории, фабрики, хендлеры команд, контроллеры - все это сервисы.
В User Interface Layer - это контроллеры (те что в Yii называют контролерами, у этого термина есть другие применения), сериализаторы запросов и ответов, middleware, валидаторы
В Application Layer - сервисы объединяющие разные части вашего приложения, например хендлеры команд если они используются
В Domain Model - доменные сервисы, сложные процессы, код которых можно безболезнено вынести из сущности, т.к. является вспомогательным, и может быть использован другими сущностями
В Infrastructure Layer - это мапперы, адаптеры внешних систем и т.д.
Другие термины, которые в этой теме использованы:
Репозитории - понятие применяющиеся в разных контекстах, и смысл соотв. разный.
Есть репозиторий из DDD, предложенный Евансом, это сервис на который возложена ответственность работы с однотипными сущностями,
другими словами Репозиторий это Коллекция (список) сущностей одного класса. Это сервисы доменного слоя.
Есть репозитории как сервисы инфраструктурного слоя, ответственность которых сохранить в хранилище (БД, файлы, др.)
Иногда совмещают это в один класс.
DTO - объект-значение, которое применяют для обмена информацией между слоями. Не забываем что объект-значение неизменно.
slavcodev писал(а):2. Сервисы - объект модель како-либо процесса. Сервисы не имеет состояния, его ответственность изменить состояние объектов-данных, вычислить что-либо, и т.д..
Но очень часто "сервисами" называют только классы из "сервисного слоя" (Service Layer).
Термин появившийся, ИМХО, по ошибке, при неверном толкования MVC, не хватало чего то между "C" и "M",
придумали "сервисный слой", и стали туда переносить часть "C".
Т.е. если рассматривать Service Layer, то это класс, который содержит часть логики из контроллера (вычисления, какие-то манипуляции с данными). А в контроллере потом вызываются методы Service Layer в нужном месте? Если рассматривать сервисный слой в этом контексте, где его лучше размещать, в той же дирректории, где и контроллер (относительно yii2)?
Разработка на yii2 или чистом php.| email: site4coder@gmail.com | skype: for-web1
magicoder писал(а):Т.е. если рассматривать Service Layer, то это класс, который содержит часть логики из контроллера (вычисления, какие-то манипуляции с данными)
на этот вопрос сложно ответить без улыбки, поскольку в контроллере логики не должно быть никакой кроме как разруливающей данные между реквестом и следующим слоем. Но в контексте типичного говнокода да, верно.
magicoder писал(а):А в контроллере потом вызываются методы Service Layer в нужном месте?
так точно
magicoder писал(а):Если рассматривать сервисный слой в этом контексте, где его лучше размещать, в той же дирректории, где и контроллер (относительно yii2)?
вопрос важный для понимания архитектуры)
подходы бывают разные. Если мы пишем слоистую архитектуру, то наш код должен быть логично поделен на слои (это не требование, но упорядочивает первый уровень кода для разработчика). Контроллеры - это слой презентации, непосредственного взаимодействия с внешним миром. Сервисы - слой приложения, клей между контроллерами и бизнес-слоем. Так бы я и делил:
слои в разной литературе названы по разному в зависимости от развития идеи и уклона конкретной подачи. Presentation/Application/Domain/Infrastructure - по-моему трактовка Эванса
