Слой прикладной службы как статические классы

Несколько ответов привели примеры использования графиков (например, сетевое моделирование), и вы спросили: «Какое отношение это имеет к программированию?».

Ответ на этот вопрос заключается в том, что он не имеет большого отношения к программированию. Это связано с решением проблем.

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

Я уже больше года использую CodeIgniter. По большей части мне это очень нравится (я участвую в форуме и использую его в каждом случае, который я могу), но я НЕНАВИЖУ ВЫСОКОМЕРИЕ этого утверждения в руководстве:

Разрушает глобальный массив GET. С тех пор CodeIgniter не использует GET последовательности, нет причин разрешать это.

Предположение, что в приложении CodeIgniter вам никогда не понадобится GET, - asinine! Уже через несколько дней мне пришлось иметь дело со страницами обратной публикации от PayPal и ClickBank (я уверен, что есть миллион других). Угадай что, они используют GET!!!

Есть способы остановить это squashing GET, но это вещи, которые имеют тенденцию портить другие вещи вверх. Что вы не хотите слышать, так это то, что вы должны перекодировать все свои представления, потому что вы включили строки запросов, и теперь ваши ссылки нарушены! Внимательно прочитайте руководство по этому варианту!

Один из них, который мне нравится (но не сработал, потому что настройка REQUEST_URI в config.php нарушила мой сайт), это расширение класса Input:

class MY_Input extends CI_Input
{
        function _sanitize_globals()
        {
            $this->allow_get_array = TRUE;
            parent::_sanitize_globals();
        }
}

Но лучший способ без всякой ерунды - проверить с помощью print_r ($ _ SERVER) по URL, где вам нужны переменные GET. Узнайте, какой параметр протокола URI отображает переменные GET и использует их.

В моем случае я вижу, что мне нужно в REQUEST_URI

// defeat stupid CI GET squashing!
parse_str($_SERVER['REQUEST_URI'], $_GET);

This помещает последовательность запроса обратно в суперглобальный $ _ GET для этого экземпляра страницы (Вы не должны использовать $ _ GET, это может быть любая переменная.)

EDIT

После публикации я обнаружил, что при использовании REQUEST_URI вы потеряете свой первый запрос последовательности ключ массива, если вы не удалите все до?. Например, URL-адрес, как/controller/method? one = 1 & two = 2, заполнит массив $ _ GET в этом примере массивом ('method? one' = > 1, 'два' = > 2). Чтобы обойти это, я использовал следующий код:

parse_str(substr(strrchr($_SERVER['REQUEST_URI'], "?"), 1), $_GET);

Я полагаю, я должен был предоставить пример, так что здесь:

class Pgate extends Controller {
   function postback() {
      parse_str(substr(strrchr($_SERVER['REQUEST_URI'], "?"), 1), $_GET);
      $receipt = $this->input->xss_clean($_GET['receipt']);
   }
}

Ваш подход к этому действительно не рекомендуется. Лично я бы никогда не допустил такого подхода в своей команде. Недостатки:

1. Основные проблемы многопоточности, как вы испытываете, которые не просто решить
2. Вы не можете проверить это очень легко.
3. Нереалистичная абстракция доступа к данным

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

В любом случае следует просто создать экземпляр репозитория как часть классов базовых служб. Нет причин, по которым это должен быть «статический ИЛИ вызов экземпляра везде». Внутри базовых классов должен быть ограничен код экземпляра.