2015-12-10 3 views
3

Я строю веб-приложение, которое имеет 3 Сторонние API интеграции, которые включаютГде вызов API находится в приложении laravel шаблона репозитория?

  1. Платежные шлюзы
  2. Sms поставщиков
  3. провайдеров электронной почты, как Mandrill

Теперь я могу иметь конкретные классы хранилища где функции, которые говорят с моей БД, находятся. Насколько я знаю, репозитории находятся в стандартной практике, используемой для общения с базами данных. Теперь, где я строю логику вызова стороннего API? Это то, для чего предназначен поставщик услуг? Если тогда кто-нибудь покажет мне очень простой пример того, как работает весь поток? Например, для отправки sms с контроллера путем вызова поставщика услуг. Этот вопрос может показаться дампом, но я не могу получить какие-либо примеры или поток, просматривающий его в Интернете. Нет реальных примеров для мира.

Просьба указать ссылку или пример, если кто-то сделал то же самое.

TIA!

+0

Есть несколько учебников относительно [шаблона репозитория laravel] (https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/). большинство из них предлагают использовать * настраиваемый PHP-код в некоторых пространствах имен * и интерфейсных классах. И отметить, что laravel имел [mandrill support] (http://laravel.com/docs/5.1/mail). пс. первый результат google на [laravel sms] (https://github.com/SimpleSoftwareIO/simple-sms), также я нашел на [packagist] (http://packalyst.com/packages/tag/sms). просто копайте немного глубже, если вы застряли, попросите людей в sof. –

+0

Привет @Tezla учебники ограничены только доступом к базе данных и данным внутри самого веб-приложения. Указывается на то, как структурировать внешний API. У Codeigniter были библиотеки, где мы могли бы использовать всю внешнюю интеграцию api. Но в лараве это стандартный способ сделать это? То, что там нет в учебниках – Ajeesh

+0

, потому что ** я рассматриваю шаблон хранилища как набор пространств имен с контрактами (интерфейсные классы), которые могут что-то сделать ** - да, примеры могут быть некоторыми доступ к базе данных, но ничто не может помешать вам сделать что-то еще. В конце концов, программирование касается творчества. а также попробуйте URL-адрес пакета, вы можете найти нужные вам пакеты. и я надеюсь, что никто не начнет священные войны CI-Laravel. –

ответ

0

Хранилища в строгом смысле предназначены для инкапсуляции методов для расширенного доступа к набору данных.

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

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

Не каждый стандарт или образец идеально вписываются в ваше приложение, а также не должны. При необходимости вы должны внести необходимые изменения и разорвать соглашение. Это вопрос суждения. Если вы считаете, что проще использовать репозитории как эффективные коллекции расширенных методов доступа (с логикой приложений на другом уровне, например Services), или коллекциями логики приложения. Даже оба.

Смежные вопросы