Должны ли мы инициализировать объект класса внутри файла конфигурации?

Question

Является ли хорошей практикой инициализация объекта для класса аутентификации, который выполняет различные действия, такие как регистрация пользователя, вход в систему и т. Д. Внутри файла конфигурации?

Файл конфигурации в основном выполняет такие функции, как установка имени пользователя, пароля, имени сайта и т. Д.

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

    // MySQL connection settings
    $db_host = "localhost";
    $db_user = "someuser";
    $db_pass = "some pass";
    $db_name = "somedb";



    // Name of the site
    $site_name = "MyDomainName";   



    $auth = new auth();//initialize Authentication class
$auth->set_auth();//Check if user autorized

Answer 1

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

index.php:

include('bootstrap.php');

bootstrap.php:

include('config.php');
$auth = new auth();
$auth->set_auth();

config.php:

$db_host = "localhost";
$db_user = "someuser";
$db_pass = "some pass";
$db_name = "somedb";

Answer 2

Хорошей практикой является абстрагирование вашего кода в куски, которые в вашем случае имеют единственную цель: объект конфигурации и обработчик аутентификации.Это связано с принципом KISS , который определяет простоту конструкции.В данном случае: простота в коде.Когда вы смешиваете код, как вы описываете, ваш код становится более сложным, потому что он делает больше вещей.

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

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

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

В вашем примере я использовал бы что-то вроде этого:

<?php

include 'config.php'; // contains function that returns config object/array
include 'auth.php';   // contains functions for authentication

// determine environment, based on server variables (ip, script path, etc)
$environment = getEnvironment($_SERVER);

// get config based on environment
$config = getConfig($environment);

// see if authentication is needed
if (needsAuthentication()) {

    // perform authentication based on request variables (eg: submitted form fields)
    $auth = new auth();
    $auth->doAuth($config, $_REQUEST);
}

Answer 3

Я бы этого не делал.«Код» лучше хранить отдельно от «файлов конфигурации» по ряду причин.Во-первых, у вас может быть конфиденциальная информация в файлах конфигурации (например, пароли), и вы хотите хранить их в другом хранилище, чем сам код.Ввод инициализации (то есть кода) в Config будет означать, что она контролируется в двух исходных репозиториях.Во-вторых, вещи, которые «бегают», не могут быть идемпотентными.new auth() может установить какое-то состояние, из-за которого «перезагрузка» Config будет немного болезненной.

Лучше всего сохранять «загрузчик конфигурации», который создает объект Config, содержащий экземпляры классов и т. Д. После чтения информации из файла конфигурации, а не помещает этот код инициализации непосредственно в файл.Кроме того, я бы не рекомендовал использовать исполняемый код в качестве конфигурационного файла (хотя это кажется практикой в ​​мире PHP).Я бы использовал формат, подобный .ini или yaml, и загрузил бы его, а не оценивал код, который находится за пределами моего основного приложения.

Answer 4

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

Файл конфигурации не должен содержать ничего, кроме данных конфигурации.