Sử dụng các lớp ORM trực tiếp từ bộ điều khiển trong MVC, thực hành không tốt?

Question

Gần đây tôi đã bị xóa vào sử dụng ORM trong ứng dụng CodeIgniter của tôi và một trong những thứ tôi đã sử dụng là Propel. Bây giờ điều này mang lại cho tôi sức mạnh về cơ bản sử dụng các lớp Propels như là 'Mô hình' nhưng thực tế này có tệ không?

Vì vậy, mã điều khiển của tôi sẽ như sau:

<?php 
    class Page extends Controller { 
     function __construct() { 
      parent::__construct(); 
     } 

     function index() { 
      $foo = FooQuery::create()->limit(10)->find(); 
      $data['content'] = array('foo'=>$foo); 
      $this->load->view('home', $foo);  
     } 
    } 
?> 

tôi muốn giải quyết vấn đề này trước khi tôi tiếp tục phát triển ứng dụng của tôi. Một ví dụ về làm thế nào tôi nên làm điều này sẽ rất hữu ích nếu bạn xem xét việc này để được thực hành xấu xin vui lòng.

Cảm ơn trước

Answer 1

Vâng, thực tiễn không tốt.

Mô hình phải chứa tất cả logic dữ liệu của bạn và trừu tượng hóa nó hoàn toàn khỏi phần còn lại của chương trình. Đối với phần còn lại của ứng dụng, các mô hình sẽ trông giống như các hộp đen, trong đó nó lấy dữ liệu của nó. Nếu bạn sử dụng ORM làm mô hình của mình, bạn là leaking the abstraction và kết nối chặt chẽ bộ điều khiển với lớp dữ liệu của bạn.

Thay vào đó, hãy tạo mô hình của bạn và xử lý ORM trong đó. Bằng cách đó nếu bạn cần điều chỉnh mô hình dữ liệu của mình, bạn chỉ có thể thay đổi nó ở một nơi (lớp mô hình) và biết rằng trừu tượng sẽ giữ.

Answer 2

Tôi nhận thấy điều này là một điều ác khi cần thiết khi ORM của bạn đang theo mẫu Active Row.

Vấn đề tôi luôn gặp phải là mô hình chỉ đại diện cho một cá thể duy nhất của cấu trúc dữ liệu. Nó không có ý nghĩa để thêm các phương thức truy xuất bộ sưu tập vào mô hình.

Đây là nơi tôi đã sử dụng lịch sử một lớp dịch vụ để xử lý việc kéo trong các bộ sưu tập mô hình. Mặc dù phải trung thực gần đây tôi đã chỉ đơn giản là viết một đối tượng trợ giúp điều khiển mà chỉ tóm tắt đối tượng bảng của tôi.

Answer 3

Với các lớp Query Sử dụng ngay bây giờ, tôi nghĩ sự khác biệt với Mô hình "chính thức" càng trở nên nhỏ hơn và nhỏ hơn. Nếu điều này sẽ trở thành một thư viện mà bạn phát hành vào thế giới, nó sẽ là một lợi thế để có một lớp trừu tượng để bạn có thể có các backend khác nhau, nhưng nếu nó là một ứng dụng trong nhà tôi sẽ chỉ sử dụng các lớp Query làm Mô hình của bạn.

Nhưng hãy nhớ rằng các lớp Query được tạo để cảm thấy giống như một đối tượng thực tế và chúng ẩn phần quan hệ nhiều nhất có thể. Bạn có thể sử dụng điều này để lợi thế của bạn. Kiểm tra this article about rewriting your SQL queries with Query methods, đặc biệt là câu trả lời thứ ba: di chuyển nhiều hơn và nhiều hơn nữa vào lớp Query của bạn, do đó Trình điều khiển của bạn không cảm thấy như nó sử dụng cơ sở dữ liệu.

// Instead of this code in your controller, 
// tightly coupled to your database logic 
$books = BookQuery::create() 
    ->filterByTitle('%war%') 
    ->filterByPrice(array('max' => 10) 
    ->filterByPublishedAt(array('max' => time())) 
    ->leftJoin('Book.Author') 
    ->where('Author.Name > ?', $fameTreshold); 

// You would use this code in your controller 
// and create small methods with the business logic in the BookQuery class 
$books = BookQuery::create() 
    ->titleContainsWord('war') 
    ->cheap() 
    ->published() 
    ->writtenByFamousAuthors(); 

Answer 4

Nó phụ thuộc rất nhiều vào những gì bạn đang làm và tại sao. trong ví dụ này, bạn đang đặt mệnh đề giới hạn trong truy vấn - đó là logic nghiệp vụ hay hiển thị? Theo quan điểm của tôi, thật khó để lập luận rằng đó là logic kinh doanh - rằng tôi lấy lại 10 yếu tố không liên quan đến mô hình - đó là số lượng tôi nghĩ có ý nghĩa khi sử dụng trong một trang. Nếu bạn muốn quy tắc đó nhất quán giữa các bộ điều khiển, bạn có thể đặt một số giá trị cấu hình để thực thi tính nhất quán. Nhưng đặt nó vào mô hình chỉ làm cho mô hình không cần thiết lớn (có sự khác biệt giữa các mô hình chất béo và các mô hình béo phì)

Tôi sẽ nói rằng giới hạn, đơn đặt hàng và bù đắp thường không logic kinh doanh. Ngay cả một đơn giản, nơi có thể hoặc có thể không được tùy thuộc vào vụ án.Nếu có một tham gia ở đó, đó là một dấu hiệu cho thấy có điều gì đó không ổn.

Ví dụ từ Jan Fabry chủ yếu là khá tốt. filterByTitle trông giống như tôi với titleContainsWord. filterByPublishedAt (mảng ('max' => time())) tệ hơn nhiều so với -> published(). Nói chung, ít bộ điều khiển bạn cần phải biết về cấu trúc dữ liệu bên trong, thì càng tốt.