2013-06-13 18 views
16

Tôi có câu hỏi về các phương pháp hay nhất trong Symfony 2. Xin lỗi nếu có chút mơ hồ và chủ quan. Tôi đoán tôi có thể tổng hợp câu hỏi của mình là:Thực hành tốt nhất của Symfony. Truy vấn có nên nằm trong kho hoặc dịch vụ không?

"Các kho lưu trữ có luôn đúng chỗ cho các truy vấn không?".

Hiện tại, tôi đang đặt hầu hết các truy vấn học thuyết của mình vào kho lưu trữ thực thể. Hầu hết các hành động điều khiển của tôi làm những việc điển hình như truy vấn cho một thực thể hoặc tập hợp các thực thể, ném một ngoại lệ hoặc chuyển hướng tùy thuộc vào kết quả của điều đó, nếu không cập nhật một hoặc nhiều thực thể. Hầu hết các hành động phức tạp hơn có thể được thực hiện hiệu quả với các truy vấn chuẩn -> find, -> findBy etc. Hầu hết yêu cầu tham gia. Khi một truy vấn liên quan đến nhiều thực thể, đôi khi tôi không chắc chắn kho lưu trữ nào nên đi vào. Tôi đoán có thực thể gốc của truy vấn nhưng ... đôi khi dữ liệu từ các thực thể được kết nối quan trọng và có liên quan hơn để đặt nó vào kho chứa của thực thể gốc.

Điều đó hoạt động tốt nhưng tôi có xu hướng kết thúc với nhiều truy vấn gần giống nhau nhưng hơi khác nhau trong kho của tôi. Đến với tên và theo dõi chính xác những gì mỗi người làm có thể gây nhầm lẫn và tẻ nhạt. Hầu hết các truy vấn này chỉ được sử dụng bởi một hoặc hai (thường hiếm khi được sử dụng) các hành động điều khiển trong cùng một bộ điều khiển. Tôi cảm thấy như tôi đang làm lộn xộn kho của mình với quá nhiều công cụ chuyên dùng, ít khi được sử dụng.

Dường như tất cả nhưng hành động đơn giản nhất phải được đóng gói trong một đối tượng hoặc dịch vụ. Vì vậy, tôi đã bắt đầu thực hiện rất nhiều truy vấn của mình trực tiếp trong dịch vụ chứ không phải là một kho lưu trữ. Thật dễ dàng để xem xét hành động ở một nơi. Đây có phải là một thực hành không sao?

+1

bộ điều khiển phải là một lớp thực sự mỏng giữa thế giới ứng dụng và thế giới http và tôi khuyên bạn nên luôn đặt các truy vấn vào kho lưu trữ. –

Trả lời

9

truy vấn của bạn nên được giữ trong tổ chức của bạn kho và không có trong bộ điều khiển của bạn để có thể tái sử dụng chúng dễ dàng.

Đó là những gì các kho lưu trữ thực sự. Cung cấp vị trí có thể sử dụng lại cho các truy vấn cơ sở dữ liệu.

Tuy nhiên, có một số trường hợp giữ tất cả các truy vấn của bạn trong kho lưu trữ ... đặc biệt là khi nói đến việc lọc nhanh nơi cần nhiều truy vấn.

Benjamin Eberlei (tác giả của Doctrine) xem xét 5 phương pháp công khai trong lớp học là ổn và 10 là khá lớn. Gần đây, ông đã xuất bản một bài viết thú vị có tên "On Taming Repository Classes in Doctrine" về điều này trên blog của mình.

Tôi phần nào giống như giải pháp tính trạng kho lưu trữ có thể lọc bởi KnpLabs trong số DoctrineBehaviors của chúng tôi.

Đặc điểm kiểm tra khó khăn hơn nhưng bạn có thể có một kho lưu trữ ... nơi bạn nên giữ truy vấn.

+2

Cảm ơn các liên kết, cả hai đều thú vị. Tôi sẽ không đặt các truy vấn trong bộ điều khiển của mình. Tôi chỉ đang tìm một cách để tránh bloating kho của tôi với rất nhiều tương tự nhưng không hoàn toàn giống các truy vấn có tên tương tự nhưng không hoàn toàn giống nhau. – tetranz

9

Bạn có thể thực hiện điều gì đó giữa chừng.

Xác định một dịch vụ:

blog.post_manager: 
    class: Acme\BlogBundle\Entity\Manager\PostManager 
    arguments: 
     em: "@doctrine.orm.entity_manager" 
     class: Acme\BlogBundle\Entity\Post 

Sau đó tạo lớp Manager:

use Doctrine\ORM\EntityManager; 
use Doctrine\ORM\EntityRepository; 

class PostManager 
{ 
    protected $em; 

    protected $repo; 

    protected $class; 

    public function __construct(EntityManager $em, $class) { 
     $this->em = $em; 
     $this->class = $class; 
     $this->repo = $em->getRepository($class); 
    } 

    public function get($id) 
    { 
     return $this->repo->findById($id); 
    } 
} 

Bằng cách này, bạn vẫn có thể để lại các truy vấn mà họ thuộc về, trong kho, trong khi cho phép mã tái sử dụng thông qua dịch vụ quản lý có thể được sử dụng như thế này trong bất kỳ trình điều khiển nào:

$this->container->get('blog.post_manager')->get(1); 

Kể từ khi dịch vụ băng chăm sóc tiêm lớp và quản lý thực thể cho lớp Manager, điều này cũng giữ cho bộ điều khiển mỏng hơn và tốt hơn để tóm tắt nó khỏi mô hình.

+1

Lớp người quản lý +1 là một mẹo hay mặc dù câu hỏi thực sự là nơi để giữ các truy vấn của mình - hầu như luôn luôn là kho lưu trữ. Lớp người quản lý cung cấp lợi thế của việc trừu tượng hóa các cách khác nhau để truy cập cơ sở dữ liệu của bạn. bạn có thể có một lớp người quản lý bằng cách sử dụng kho lưu trữ thực thể, một lớp khác sử dụng kho lưu trữ tài liệu khác bằng cách sử dụng một chương trình phụ trợ lưu trữ hoàn toàn khác. miễn là chúng đều thực hiện cùng một giao diện, bạn có thể trao đổi chúng trong bộ điều khiển của bạn. Đó là cách FOSUserBundle xử lý doctrine orm, odm và propel :) – nifr

+1

"Bằng cách này, bạn vẫn có thể để lại truy vấn nơi chúng thuộc về, trong kho, [...]" –

+0

ah nó ẩn trong đó, xin lỗi là tốc độ đọc :) – nifr

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