2012-01-19 27 views
5

Gần đây tôi đã học được giá trị của việc tiêm phụ thuộc nhưng tôi tự hỏi liệu tôi có nên sử dụng nó trong dự án của mình vì tôi thậm chí không yêu cầu một mvc thổi hoàn toàn. Bây giờ tôi đang sử dụng nó, tôi nhận ra thêm chi phí trên mỗi trang mà tôi viết. Ví dụ ...Tôi có nên sử dụng tiêm phụ thuộc trong dự án php của mình không?

require_once '../../include/session.class.php'; 
    require_once '../../include/db.class.php'; 
    require_once '../../include/account.class.php'; 

    $objSession = new Session(); 
    $objDb  = new Db(); 
    $objAccount = new Account($objSession, $objDb); 

account.class.php

class Account { 
    ... 
    public function __construct(Session $objSession, Db $objDb) { 
     $this->session = $objSession; 
     $this->db = $objDb; 
    } 
} 

... lớp Account sẽ luôn luôn cần Db và Session và tôi sẽ chỉ bao giờ có một lớp của mỗi. Vì vậy, câu hỏi của tôi là, tôi nên sử dụng DI trong một tình huống như thế này hay nên tôi chỉ sử dụng ...

account.class.php

require_once '../../include/session.class.php'; 
require_once '../../include/db.class.php'; 

class Account { 
    ... 
    public function __construct() { 
     $this->session = new Session(); 
     $this->db = new Db(); 
    } 
} 

...?

+5

Dependency Injection không chỉ dành cho MVC, đó là thực hành tốt trong một loạt các dự án cho dù bạn đang sử dụng một khung công tác hay không. –

+1

Xin lỗi, không có ý định ngụ ý rằng nó là, chỉ rằng dự án này không yêu cầu một. – Isius

+0

Bạn thực sự có thể làm cho mã sạch hơn rất nhiều bằng cách chỉ cần thực hiện một autoloader để bạn có thể mương tất cả các yêu cầu (ngoại trừ các yêu cầu cho autoloader tất nhiên). – GordonM

Trả lời

6

Tính phụ thuộc Không có gì liên quan đến MVC. Nó thực sự tốt trong việc thực hiện các bài kiểm tra đơn vị dễ dàng hơn để viết và cuối cùng tôi đã thấy rằng nó làm cho tôi thực sự suy nghĩ về các nguồn tài nguyên mà tôi đang sử dụng và việc triển khai có nên sử dụng tài nguyên đó hay không.

Cá nhân tôi không thấy tác hại trong việc tạo đối tượng được tiêm, vì vậy bạn có một vài dòng mà bạn phải tạo đối tượng? Nó cho người dùng biết nhiều hơn về những gì đang xảy ra. Tôi muốn có sự rõ ràng hơn so với phép thuật.

Cá nhân, tôi cho rằng phần lớn sự lộn xộn trong mã đến từ các tuyên bố require. Tôi muốn nói một autoloader sẽ giải quyết một số vấn đề đó.

Tôi thực sự thích điều này Google Clean Code Talk on DI. Nó giúp tôi nắm bắt được khái niệm và lợi ích của nó tốt hơn một chút.

+0

Tôi đã xem Google Talk nhiều lần trong quá khứ. Nó thực sự là tốt! – Steven

0

Container tiêm phụ thuộc được phát minh để giải quyết vấn đề này. Xem xét:

$account = DependencyInjectionContainer::build('Account'); 

Lớp DependencyInjectionContainer sẽ xử lý các tiêm:

public static function build($class) { 
    switch ($class) { 
     case 'Account': 
      $session = new Session(); 
      $db = new Db(); 
      return new Account($session, $db); 

     // ... 
    } 
} 
1

Bạn đã đọc về những giá trị của dependency injection. Tại sao bạn bắt đầu sử dụng nó?

Có phải vì khả năng trao đổi những phụ thuộc cụ thể đó cho thử nghiệm hoặc môi trường khác nhau không? Liệu nó có tách biệt và làm rõ trật tự của một chuỗi phụ thuộc vòng tròn?

Giả sử, ví dụ, mong muốn đưa các lớp khác nhau vào mục đích thử nghiệm (giá trị của DI đã khiến tôi sử dụng nó). Làm thế nào để bạn xử lý mà không có DI?

Xem lớp Tài khoản của bạn. Bạn có thể sửa đổi hàm tạo với một kiểm tra trên một số thuộc tính testMode(), hoặc bạn có thể sửa đổi các hàm tạo Db và Session, hoặc bạn có thể thay đổi tệp cấu hình. Bất kỳ giải pháp không DI nào bạn chọn, bạn có ổn không? Điều gì về phụ thuộc khác (emailer, logger, vv)? Bạn có bất kỳ giao diện nào với các hệ thống bên ngoài mà bạn nên thử nghiệm không?

Dù sao, câu trả lời có thể là bạn hài lòng mà không có giải pháp DI và ứng dụng của bạn đủ nhỏ để quản lý mà không có nó.Nhưng điều quan trọng là hãy tự hỏi mình câu hỏi.

Tương tự, hãy áp dụng cùng một dòng câu hỏi đó cho các giá trị khác của DI đã thúc đẩy bạn bắt đầu sử dụng nó.

Ngẫu nhiên, bạn có một ví dụ về Db trong Tài khoản và một trường hợp khác trong mỗi lớp khác của bạn không? Bạn có thể chỉ có một ví dụ? DI giúp với điều đó. Bạn có thể có các lớp singleton mà không thực sự mã hóa chúng như là singletons bởi luôn luôn tiêm cùng một thể hiện.

Ngoài sự tò mò, tại sao bạn lại thực hiện việc tiêm phụ thuộc của riêng mình thay vì sử dụng thư viện DI? Một nửa lợi ích của việc sử dụng DI là nó được tóm tắt một cách rõ ràng bởi các triển khai của người khác. Chỉ viết mã bạn cần và để cho các thư viện xử lý việc tiêm cho bạn. Điều này tương tự như đề xuất của drrcknlsn, nhưng không cần viết triển khai thực tế của lớp DependencyInjectionContainer:

$ account = DependencyInjectionContainer :: build ('Account');

và vặn phần còn lại.

Một thư viện DI tốt sẽ thấy hàm tạo cho Tài khoản, nhận ra nó cần một Db và một phiên, và di chuyển chuỗi các nhà xây dựng (trong trường hợp này, nó kết thúc ở đó vì cả hai đều có các hàm tạo rỗng). Điều đó có nghĩa là có cùng số lượng mã như trường hợp DI (cộng với các đối số cho hàm tạo, trừ các lời gọi đến các hàm tạo bên trong, nhưng không có thêm crap ở đầu), với bất kỳ lợi ích nào đã đưa bạn đến DI ngay từ đầu.

Các vấn đề liên quan