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

Question

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

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

1-й метод

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.

2-й метод

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? Кроме этих двух методов, есть ли другие хорошие способы?

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

7

codeigniter oop php service-layer

Решение

Другие решения

ИМХО тут нет правильного или неправильного

Опция 1 —
Если вы хотите повторно использовать сервисный уровень в нескольких контроллерах / действиях
и подавать данные из разных моделей на основе запроса, имеет смысл перейти к первой.

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

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

0

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

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

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

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

Например фейсбук / твиттер
Они оба имеют функцию запроса и ответа, но оба следуют одинаковым шаблонам, но имеют разные конечные точки.

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);
}
}

Внедрение зависимостей требуется здесь

new MyController( new SocialMediaServiceProvider ( new FacebookService ) )

0

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

-1

Источник

Accepted Answer

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

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

Плюсом является то, что фреймворки, такие как, например, Symfony, предоставляют исходную взвешенную архитектуру, которая, по крайней мере, содержит некоторую форму согласованности в приложении, и она выглядит примерно так:

Стандартный HTTP-запрос приходит и попадает на фронт-контроллер, как правило, app.php или же app_dev.php в зависимости от того, находитесь ли вы в разработке или производстве; один включает в себя большое кэширование, которое необходимо запускать при каждом изменении, а другое — нет, что идеально подходит для разработки.
Маршрутизатор сопоставляет текущий URL с классом контроллера и «действием» (методом) в этом классе.
Часть внедрения зависимостей каркаса выясняет, какие объекты необходимы для всего, от контроллера до уровня модели и обратно, и либо создает экземпляры, либо готовится к их созданию при необходимости.
Контроллер создается с любыми необходимыми зависимостями и выполняется соответствующий метод. Обычно вы начинаете свою разработку и «подключаете свой код» к фреймворку.
Именно здесь вы выбираете свою архитектуру, однако самое важное с точки зрения разработчика и бизнеса (для снижения затрат на техническое обслуживание в будущем) консистенция.
Я лично предпочитаю, чтобы мой код был отделен от фреймворка. Я передаю скаляры, взятые из запроса, в службу уровня приложения, которая использует объекты из уровня модели (переданные через DI) для использования объектов домена. Дело в том, что доменные объекты не передаются напрямую в контроллер, они проксируются через среду уровня приложения, так что вы можете теоретически заменить всю инфраструктуру, окружающую это, и все же, все, что вам нужно сделать, это передать эти скаляры в этот уровень до того, как они попадут на уровень модели, и все будет работать (думаю, что вызовы CLI, контроллеров больше нет).
Служба уровня приложения использует любые необходимые Repositories, Services и т. д. (и передает эти скаляры в них, помните разделение?), которые выполняют бизнес-логику (как правило, именно здесь ваши шаблоны проектирования вступают в игру на ежедневной основе), а затем возвращают эти данные в приложение. уровень сервиса.
Служба затем возвращает данные в контроллер и угадайте, что? Это где рамки имеют тенденцию облажаться! Потому что в современных рамках нет понятия «вид». Существует только шаблон, и вы передаете эти данные в шаблон, и все. Итак, на вашей диаграмме нет абсолютно никакой концепции представления, потому что это не так. И, честно говоря, я все еще использую шаблоны, потому что они — самый быстрый способ сделать что-то, но пока современные фреймворки не соберутся и не начнут использовать Views, нам не повезло, и мы должны оставаться стойкими, когда сталкиваемся тот факт, что некоторые (например, Laravel) называют себя фреймворками «mvc».

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

Итак, поскольку вам так нравятся диаграммы, вот как некоторые могут сделать это с сегодняшними фреймворками …

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

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

Видите, вы не застряли с запросом framework / http, чтобы запустить приложение в результате этого разделения.

Видите «услуги» на приведенной выше диаграмме? Они отделены от контроллера, поэтому вы можете выбросить скаляры откуда угодно, и приложение все равно будет работать. Я думаю, что это даст вам необходимое разделение. Здорово делать все правильно, учиться тому, как это делать, а затем учиться контролировать себя и быть прагматичным в этом, когда дело касается бизнеса и его потребностей, но фреймворки должны разобраться со своими вещами — и вы, конечно, не будете писать прекрасный код с CodeIgniter;)

9