Singleton и конфиги

...кроме работодателя.

Рынок труда - это улица с двусторонним движением. Работадатель и наёмник, продавец и покупатель, заказчик и подрядчик - каждый разруливает свою выгоду.

У меня в движке 100500 разных доступов

+100 в карму. Сам люблю контроль тотальный. Единственно что не стоит забывать, что в конфиги лезут крайне редко. Раз настроил и пипл юзает. И нафиг им не надо осваивать "новый" функционал. Потребителя интересует только одно - как можно меньше напрягаться за обговоренную зп. В идеале посещать офис пару раз в году - на корпоратив :beer:
Хочешь порадовать коллег - сделай так чтобы была одна кнопка - нажал и работа сделалась и будешь всеобщим любимцем :sun:
 
Хочешь порадовать коллег - сделай так чтобы была одна кнопка - нажал и работа сделалась и будешь всеобщим любимцем
Дурное начальство может уволить.
Им невдомек, что хороший администратор должен работать не напрягаясь.

У меня так коллега уже 2 года не хочет переписывать старые программы, боится видимо, что ее уволят.
На клиппере ещё.
Даже не знаю, что она будет делать, когда я разозлюсь и переведу их хотя бы в Эксель.
 
Коллеги, можно обратится к "серийным" фреймворкам. К примеру в Simfony конфиги хранятся в *.yml файлах. Посмотрите, мне кажется удобно.
 
Сериализация/десериализация медленнее, чем var_export/include.

А вообще зачем городишь такой велосипед, храни все в $global, а если там пусто загружай из файла.
 
Сериализация/десериализация медленнее, чем var_export/include.
Лет 5 назад так и было сейчас надо тестить.
А вообще зачем городишь такой велосипед, храни все в $global, а если там пусто загружай из файла.
Глобал как собственно и синглтон, считается антипатерном в силу сложностей с тестированием и разрастанием косяков, когда эти глобалы меняются из разных мест.
 
Лет 5 назад так и было сейчас надо тестить.

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

Смутно догадываюсь, что мои проблемы с синглтонами еще возникнут. Но что же взять в качестве альтернативы синглтону. Где хранить данные для повторного использования? Вот к примеру конфиг в ini файле. Не будешь же его парсить каждый раз, когда нужна какая-то настройка.
Хорошо бы в faq хорошие паттерны проектирования собрать.
 
The biggest performance hit for any single request in the system is the XML / INI / JSON, rather than the accessing of it via whichever syntax you decide to go with.
 
Храните конфиги в виде массивов:

config.php
PHP:
<?php

return [
     'param' => 'value'
];

ConfigStorage.php
Код:
<?php

class ConfigStorage
{
    private static
        $configs = [];
  
    public static function getInstance($config_name)
    {
        if (!isset(self::$configs[$config_name]))
        {
            self::$configs[$config_name] = require('path/to/config/'.$config_name.'.php');
        }
        return self::$configs[$config_name];
    }
    private function __clone() {}
    private function __construct() {}
}

В этом коде есть проблема, кто скажет какая ?

Проблема в том, что сторадж конфига должен быть конфигурируемым и работать с соответствующим провайдером, это как раз и есть решение вопроса, коогда есть разные виды серверов (обычный хостинг, выделенный сервер етц c разным набором софта). Тогда просто конфигурируется соответствующий провайдер, который умеет работать с редисом, файловой системой, мемкешом и имеет метод get, который реализует логику ключ значение, если ключ пустой, взяли из сконфигурированного места соответствующий конфиг и сложили его либо в память в рамках процесса, либо в redis, memcached в рамках ttl.
 
Назад
Сверху