Databases
StackOverflow2013
Postsdbo
POWhen is Dependency Injection necessary in PHP?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhen is Dependency Injection necessary in PHP?
    primarykey
    data
    text
    <p>Is Dependency Injection (DI) something that's more important for large enterprise applications with multiple team members? Right now I'm a single developer trying to hack out a small site to see if it gains traction. However, I am not convinced that DI will add value to the code I'm writing, despite overwhelming support by this community. </p> <p>I've spent the last week researching DI and implementing in my code, which is not difficult just time consuming. But I still do not see the benefits in decoupling and unit testing. Instead, it seems to make the code more difficult to understand, take longer to write, and may have performance issues. Before I waste anymore time implementing DI, I am interested in the following issues being addressed.</p> <p>1) Benefits in Decoupling? I don't see how DI makes code less dependent. Code by its nature needs to depend on each other for it to work. DI just moves this dependency to another area where you don't see it. For example, suppose I had a method that calls on another static method.</p> <pre><code>class User { // Static Dependency // function process_registration() { if(Form::validate($_POST['email'])) { Message::send_message("Registration Complete"); } } // Dependency Injection // function __construct($form, $message) { $this-&gt;form = $form; $this-&gt;message = $message; } function process_registration() { if($this-&gt;form-&gt;validate($_POST['email'])) { $this-message-&gt;send_message("Registration Complete"); } } } </code></pre> <p>DI would not change <code>process_registration</code>'s dependency on the <code>Form</code> and <code>Message</code> classes. Even if they were injected into the 'User' class as properties, wouldn't <code>process_registration</code> <em>still depend</em> on its class properties to work? Additionally, if I had a Container that injected the properties into the 'User' class, wouldn't the method <em>also</em> be dependent on Container for instantiating its class? Suppose I refactored 'process_registration' into another class in the future or reused it for a different project. The method will stop working regardless if DI is being used because the same class properties and injection container may not exist.</p> <p>2) Code Readability? As you can see from the example above, the code required for the <code>process_registration</code> method has now doubled. More than doubled if you consider the Container class I need to modify every time I instantiate a new class, or every time I modified a class method. Aside from that the code is less intuitive now. How are properties such as <code>$database</code>, <code>$form</code>, and <code>$message</code> related to a <code>User</code>? The code is also less elegant. Previously, my static method was <code>!Form::validate()</code>, two words. Now, it's <code>$this-&gt;form-&gt;validate()</code>, 30% longer. This affects all my methods I've injected into the class. So now when I look at a page of code it's <code>$this-&gt;</code>, <code>$this-&gt;</code>, <code>$this-&gt;</code> repeated a hundred times instead of static methods that are immediately descriptive. Instead of <code>$user=new User($user_id);</code> now its <code>ioc::get('user')-&gt;newUser($user_id);</code>. My point is that DI encourages non-PHP standard idiomatic code.</p> <p>3) Better Performance? Rather than calling a method Just In Time when it is ready to be used, DI encourages instantiation of objects that may never be used (e.g. when validation fails or errors are thrown). This can be a performance issue if those objects have huge libraries and are heavy to load (e.g. PHPExcel). What would be the work around to this?</p> <p>4) Unit Testing? Is code testing necessary for small to medium sized projects? Right now PHP informs me when there's an error in my code. They're usually pretty easy to pinpoint and fix by checking the error_log. Would this be an issue if I needed to scale up my project in the future? If not, when will DI be necessary for testing purposes?</p> <p>For the above reasons, I have found that it is not necessary to implement DI into my project. However, I am interested in when and where it would be necessary to implement so I can do so appropriately. Please give your own detailed examples and support with reasoning. I am not interested in links to other articles because they can be quite unclear. Thanks in advance!</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USAnonymous
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhen is Dependency Injection necessary in PHP?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POWhen is Dependency Injection necessary in PHP?
      1. USmvladk
      1. VTFavorite
    3. VO
      singulars
      1. POWhen is Dependency Injection necessary in PHP?
      1. USRufinus
      1. VTFavorite
    1. COTo 4: Di is an important part for unit testing. Code might become something like "untestable" very quickly if you're not experienced in this topic. Your code with static method calls, for example, will be very hard to UNIT test as UNIT testing is about testing a *single* unit *without* its dependencies. I recommend you to do some research on this topic. Self-testing code is extremely valuable and writing it will surely enhance one's programming skills.
      singulars
      1. POWhen is Dependency Injection necessary in PHP?
      1. USDaniel M
    2. COI think that without `interface` the DI has no longer sense.
      singulars
      1. POWhen is Dependency Injection necessary in PHP?
      1. USLuca Rainone
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload