我们应该在配置文件中初始化一个 class object 吗？

Question

Is it a good practice to initialize an object for an authentication class that does various stuff like register user, login user etc. inside a config file?

The config file mostly does stuff like setting db username, password and site name etc.

Please provide a reason if you don't find this a standard practice. Just to let you know most of the code is procedural except for this particular class.

    // 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

In my opinion this is not a good idea. A config file is for configuration, not for execution . I would put this code into a bootstrap.php, so, when you have to edit your code in the future, you know exactly where you can find your configurations and instantiations.

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

The authentication class should be responsible for authenticating, not handling user-specific functions like register/edit/delete. The config object should be available to object needing the configuration data, not the other way around.

The config file should not contain anything other then config data.

Answer 3

I wouldn't do this. "Code" is best kept completely separate from the "configuration files" for a number of reasons. One is that you might have sensitive information in the config files (eg passwords) and would want to keep them in a different repository than the code itself. Putting initialisation (which is code) into the Config will mean that it is controlled in two source repositories. Secondly, stuff that "runs" might not be idempotent. The new auth() might set up some state which will make "reloading" the Config a bit of a pain.

It's best you keep a "Config loader" which creates a Config object that contains instantiated classes etc. after reading information from a config file rather than put that init code directly into the file. Also, I wouldn't recommend using executable code as a config file (although this seems to be practice in the PHP world). I would use a format like .ini or yaml and load it up rather than risk evaluating code that's outside my core application.

Answer 4

It is good practice to abstract your code into chunks that have a single purpose, in your case: a config object and a authentication handler. This is related to the KISS Principle , which dictates simplicity by design. In this case: simplicity in code. When you're mixing code, like you're describing, your code gets more complex, because it does more things.

While at first it may not seem complex, this design eventually leads to complex code. For instance: what if another developer joins your team? You'll need to add another config, and conditions to select the right config. This is also the case when working with different environments (development/production). And what if in some cases you don't want to use the authentication handler? Maybe you're executing an action that doesn't require authentication, or better yet: when authentication is unwanted. More code, more complexity.

By creating chunks of code, whether this is a class, function or an include, you're using loose coupling . This means the chunks don't know about each other, but they can interact. This interaction typically is done by giving the authentication handler a config object that it can use, rather than letting the handler decide what config it uses. This is called dependency injection and is considered a very good way of decoupling your code.

Second, quality code mostly documents itself . Let's say I have to work in your code, I don't know that including a configuration file actually does authentication. I can spend minutes, maybe hours trying to figure out why a session is created when, looking at the code, nothing seems to indicate this.

In your example, I would use something like this:

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