Правильный способ реализации уровня сервиса в приложениях CodeIgniter

Question

Ниже приведены два способа реализации уровня сервиса в приложении CodeIgniter.

первый метод

1.send request to the controller 
2.calling service layer methods from controller 
3.return processed result data set(D1) from service layer to controller 
4.then according to that data set controller demand data from model 
5.model return data set(D2) to the controller 
6.then controller send second data set(D2) to view. 

---

второй метод

1.send request to the controller 
2.calling service layer methods from controller 
3.service layer demand data from model 
4.model send requested data set(d1) to the service layer 
5.after some processing return generated data(d2) to controller from service layer 
6.then controller send data set(d2) to view. 

---

Каков правильный способ реализации уровня сервиса в CodeIgniter? Помимо этих двух методов, есть ли другие хорошие способы?

, если вы можете привести пример в коде это будет большим

Answer 1

Пожалуйста, обратите внимание, что это не обязательно правильный способ сделать это, но я собираюсь объяснить, как основа, как правило, может сделать это, и тогда вы можете узнать о других методах и выбрать наилучший один для ваш прецедент. Поэтому я не ожидаю, что этот ответ будет правильным, но я надеюсь, что он даст хотя бы небольшое представление о том, как дела обстоят прежде, чем кто-то, кто действительно знает, о чем идет речь, приходит и курит (также этим людям - не стесняйтесь редактировать/понижать этот ответ: D). Наконец, это также не имеет ничего общего с CodeIgniter, но в целом. Ваш вопрос должен быть не только сформулирован как рамка-агностик, но и язык-агностик.

Так что я собираюсь предложить мнение здесь, и это тот факт, что все современные рамки, в частности, в PHP, не делают MVC. Почему это важно? Потому что все мы должны говорить на одном языке, а «mvc» не существует в PHP. Это факт.Примите это, и тогда мы сможем продвигаться вперед к улаживанию концепции, которую используют рамки; и CodeIgnitor - это особенно яркий пример банардизации «MVC»; отныне известный как «mvc» с кавычками.

Плюсом является то, что рамки, как Symfony, например, обеспечить первоначальную упрямую архитектуру, которая содержит по крайней мере некоторую форму согласованности между приложением, и это идет что-то вроде этого:

1. стандартного HTTP запрос приходит и обращается к фронт-контроллеру, обычно app.php или app_dev.php в зависимости от того, находитесь ли вы в разработке или производстве; один включает в себя много кеширования, которое нужно запускать при каждом изменении, а другое - нет, что идеально подходит для разработки.

2. Маршрутизатор соответствует текущему URL-адресу классу контроллера и «действию» (методу) в этом классе.

3. Часть впрыска зависимостей фреймворка определяет, какие объекты необходимы для всего, от контроллера до уровня модели и обратно, и либо создает или готовит для их создания, когда это необходимо.

4. Контроллер создается с использованием любых необходимых зависимостей и выполняется соответствующий метод. Обычно это означает, что вы должны начать разработку и «подключить свой код» к структуре.

5. Здесь вы определяете свою архитектуру, однако, самое главное, как с точки зрения разработчика, так и с точки зрения бизнеса (для снижения затрат на последующее обслуживание) составляет консистенция.

6. Я лично предпочитаю, чтобы мой код был отделен от рамки. Я передаю скаляры, взятые из запроса, в службу уровня приложения, которая использует объекты с уровня модели (переданные через DI) для использования объектов домена. Дело в том, что объекты домена непосредственно не передаются в контроллер, они проксируются через среду прикладного уровня, поэтому вы можете теоретически заменить всю инфраструктуру, окружающую это, и все же все, что вам нужно сделать, это передать эти скаляры в этот слой прежде чем они попадут на модельный слой, и все это будет работать (подумайте о вызовах CLI, больше контроллеров).

7. Служба прикладного уровня использует любые требуемые Repositories, Services и т.д. (и передает эти скаляры в них, помните разделение?), Которые выполняют бизнес-логику, (как правило, это где ваши шаблоны проектирования вступают в игру в день на день), а затем возвращать эти данные службе уровня приложения.

8. Служба затем возвращает данные контроллеру и угадала, что? Вот где рамки, как правило, испорчены! Потому что в сегодняшних рамках нет понятия «вид». Существует только шаблон, и вы передаете эти данные в шаблон и bam. Таким образом, на вашей диаграмме нет абсолютно никакой концепции представления, потому что это не то, как делаются. И, честно говоря, я все еще использую шаблоны, потому что они - самый быстрый способ сделать что-то, но пока современные фреймворки не соберут свое дерьмо и фактически не начнут использовать «Представления», нам не повезло, и мы должны оставаться стойкими, когда сталкиваемся тот факт, что некоторые (например, Laravel) называют себя «mvc» фреймами.

Обратите внимание, Фабьен Potencier явно указано, что Symfony не было рамки MVC - по крайней мере, он знает, что он говорит о там.Опять же, это не пурист, важно, чтобы мы все говорили то же самое, фактически правильно язык в вычислительной технике.

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

Это для приложения, которое имеет понятие Review и Criteria для каждого Review. И даже не заставляйте меня начинать с форм Symfony, они настолько связаны со всем, что они не являются серьезной частью любой архитектуры.

Сколько эффиновых слоев вам нужно? У нас уже есть «MVC», в DDD у нас есть концепция разделения «Приложение», «Домен» и «Инфраструктура», поэтому сначала попросите этих двух работать вместе, а затем этот «сервисный уровень»? Вам действительно нужен еще один слой, или это достаточно выше? Вещи, чтобы думать о ...

See, вы не застряли с запросом рамки/HTTP, чтобы получить приложение доходя в результате этого разделения.

См. "Услуги" на приведенной выше диаграмме? Они отделены от контроллера, поэтому вы можете бросать скаляры из любого места, и приложение все равно будет работать. Я думаю, что это даст вам разделение, которое вам нужно. Это здорово делать все правильно, учиться, как это делать, а затем научиться управлять собой и быть прагматичным в этом, когда дело касается бизнеса и его потребностей, но рамки должны сортировать их вещи - и вы, конечно же, не будете писать прекрасный код с помощью CodeIgniter;)

Answer 2

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

Answer 3

ИМХО нет правильных или неправильных здесь:

вариант # 1 - Если вы хотите повторно использовать уровень сервиса в нескольких контроллеров/действий и кормить его данные из различных моделей, основанных на попросите, чтобы было целесообразно перейти к первому.

вариант 2 # - Однако первый вариант может быть проблематичным, если ваша модель данных сложнее. Что делать, если требуется второй вызов модели на основе данных первого вызова? Использование контроллера для этой бизнес-логики не соответствует всей цели сервисного уровня. В этом случае лучше было бы пойти на второй.

Я думаю, что второй из них наиболее распространенный.

Answer 4

Запуск зависимостей и шаблон адаптера были бы хорошим местом для начала. Поддержка CodeIgniter не стоит из коробки, поэтому вам нужно написать обертку или, возможно, крючок.

Ваш взгляд может поддерживать только xml | html, поскольку json должен быть предварительно отображен в .json-файл, а затем возвращен как результат, но это нужно сделать с помощью кода, проще просто вернуть объект в этом случай и изменен на интерфейсе. PHP - это встроенный язык, который работает с (xml | html)

Сервисная модель работает лучше всего, когда она вводится (зависимая инъекция) в контроллер/модель и указана как свойство этого контроллера/модели.

служба затем связан с интерфейсом

Для примера facebook/щебета Они оба имеют запрос и ответ функцию, но и следуют аналогичным моделям, но имеют разные конечные точки.Здесь требуется

interface SocialMediaAdapter{ 
    public request(url); 
    public response(); 
} 

---

public class FaceBookProvider implements SocialMediaAdapter 
{ 
    public request(url){ 

    } 
    public response(){ 

    } 

}

public class TwitterProvider implements SocialMediaAdapter 
    { 
     public request(url){ 

     } 
     public response(){ 

     } 
    } 

---

public class SocialMediaServiceProvider{ 

    protected $provider = null; 

    public function constructor(SocialMediaAdapter $provider){ 
     $this->provider = $provider; 
    } 

    public function fetch($url){ 
     return $this->provider->request($url); 
    } 
} 

Dependency Injection

new MyController(new SocialMediaServiceProvider (new FacebookService))