2011-12-02 23 views
5

Tôi đã nhận thấy rằng tất cả các kiểu máy của tôi trông rất giống nhau. Hầu hết trong số họ có xu hướng làm theo một mô hình mà họ là bộ sưu tập các phương pháp có chứa mã ghi hoạt động mà chỉ là các biến thể nhỏ trên nhau. Dưới đây là ví dụ:Mô hình của tôi tất cả có xu hướng giống nhau

class Site extends CI_Model { 

    public function get_site_by_id($id) 
    { 
     // Active record code to get site by id 
    } 

    public function get_sites_by_user_id($user_id) 
    { 
     // ... 
    } 

    // ... 

    public function get_site_by_user_id_and_url_string($user_id, $url_string) 
    { 
     // ... 
    } 

    // Non active record methods and business logic 
    // ... 

} 

Cách tiếp cận này đã làm việc tốt cho tôi nhưng tôi tự hỏi liệu có giải pháp thanh lịch hơn hay không. Có vẻ như tôi không phải tạo ra một phương pháp mới mỗi khi tôi cần tra cứu dữ liệu theo một cách mới. Đây có phải là thực tế phổ biến hoặc tôi thiếu một cách để cấu trúc lại điều này?

+1

Điều này chủ yếu sẽ là tác dụng phụ của việc sử dụng một nhóm [hồ sơ hoạt động] (http://martinfowler.com/eaaCatalog/activeRecord.html) để thay thế cho lớp chế độ được triển khai đầy đủ. Bạn có thể tìm thấy [this] (http://stackoverflow.com/a/11943107/727208) liên quan đến các tùy chọn tái cấu trúc. –

Trả lời

2

Thực hiện đúng yêu cầu của bạn, bạn có thể thêm một lớp trung gian giữa các lớp học chính mô hình (CI_Model) và lớp học của bạn (trang web), một cái gì đó giống như

class MyCommonMethodsClass extends CI_Model { 
} 

và bạn sẽ mở rộng nó trong lớp học của bạn (trang web) , trong khi đặt mã phổ biến trên đó. Điều đó sẽ có tác dụng và có thể bằng cách nào đó 'hòa nhã'. Trong thực tế vào cuối bạn sẽ kết thúc thêm crud cơ bản của bạn, hành động thích nghi trang web, với nó.

Bây giờ, nếu đó là 'sạch', đó là một điều khác. Một lần nữa, nghiêm chỉnh nói mô hình làm điều đó. Nó chăm sóc chung và 'tiên tiến' getters. Và vâng, họ hầu như luôn có khuynh hướng có cùng mã trên trang web của bạn. Vấn đề là, mặc dù có vẻ tốt đẹp trong mã của bạn (ít mã) bạn đang hy sinh kỹ thuật trừu tượng giữa logic kinh doanh của bạn và db. Bạn có phải là người mẫu thuần túy hay thực tế?

+0

+1 cho "thuần túy" và "thực tế" - quá nhiều lần, mọi người tạo ra nhiều công việc hơn cho bản thân cố gắng làm mọi thứ theo cách "đúng". – swatkins

+0

Đúng vậy, cho phép tát một ứng dụng lại với nhau và chờ đợi các vấn đề xảy ra. –

1

Tôi nghĩ rằng đây là vấn đề quan điểm nhưng tôi nghĩ thực hành tốt nhất là tạo một số kiểu Tạo, Lấy, Cập nhật, Xóa (CRUD) mô hình thực hiện nhiều hàm SQL cơ bản như GetID, UpdateByID, GetById và vv.

Mô hình CRUD chỉ có thể đi xa để giúp bạn với các truy vấn mô-đun hơn. Nhưng nó có ý nghĩa để gọi một hàm gọi là GetId và truyền một số tham số hơn là có các hàm khác nhau cho mỗi bảng.

Như tôi đã nói, CRUD chỉ có thể đi xa. Ví dụ, sẽ có ý nghĩa khi có một hàm truy vấn bảng người dùng cơ sở dữ liệu để kiểm tra xem người dùng đã xác minh và tên người dùng là & có khớp với mật khẩu hay không. Vì đây là một hàm duy nhất và không phải là một hàm trừu tượng nên cần có hàm riêng của nó được định nghĩa.

Cũng như cách thực hành tốt nhất, truy cập Logic và Cơ sở dữ liệu không bao giờ được trộn lẫn trong cùng một tệp.

0

Thực tiễn phổ biến là có các phương pháp khác nhau để xử lý việc nhận dữ liệu của bạn như vậy. Single Responsibility Principal nói rằng mọi đối tượng chỉ nên thực hiện một việc, bằng cách tạo nhiều phương thức nhận dữ liệu rất cụ thể mà bạn đang tạo mã rất dễ bảo trì và dễ bảo trì.

+0

Có thể cho các chức năng có xu hướng làm những việc cụ thể nhưng không phải cho các chức năng rất trừu tượng có thể áp dụng cho nhiều tình huống khác nhau. –

+0

Tôi cũng nghĩ rằng bạn hiểu nhầm ý nghĩa của chúng bằng 'Trách nhiệm duy nhất', điều này có nghĩa là hàm có một hành động, giống như một singleton kích hoạt kết nối cơ sở dữ liệu, nhưng vẫn có thể được sử dụng lại. 'Trách nhiệm duy nhất' là một phần của đóng gói trong OOP, đóng gói là nguyên tắc của mã có thể sử dụng lại. –

+0

Mô hình được cho là rất cụ thể, đó là điểm của một mô hình, "Trách nhiệm duy nhất" của mô hình là một kiểm tra cụ thể của tên miền, với trong mô hình bạn có phương pháp làm một nhiệm vụ cụ thể. Nếu bạn có nhiều mô hình mà tất cả làm điều tương tự thì bạn có thể có mùi mã, sau đó bạn di chuyển mã phổ biến đến một lớp mới sau đó mở rộng mô hình của bạn với lớp phổ biến. –

0

Nếu bạn có nhiều lớp cung cấp về cơ bản cùng một chức năng, thì điều này sẽ gợi ý rằng có thể có điều gì đó sai với hệ thống phân cấp lớp của bạn (cái gọi là "mã mùi"). Nếu họ có tương tác tương tự thì điều đó gợi ý rằng họ có liên quan theo một cách nào đó. Nếu đó là trường hợp thì cơ hội là tất cả chúng nên được kế thừa từ một siêu lớp chung thực hiện chức năng phổ biến cho tất cả các lớp con của bạn, với mỗi lớp con chỉ đơn giản là chuyên chức năng tổng quát của lớp cha.

Những lợi thế của phương pháp này là:

  • Bạn sẽ không lặp đi lặp lại công việc (SPOT, DRY)
  • Mã tương tác với các lớp có thể được viết một cách tổng quát hơn và có thể xử lý bất kỳ đối tượng được thừa hưởng từ lớp cha (thay thế)
0

Tôi không nghĩ có bất kỳ điều gì sai khi tạo lớp mô hình 'cơ sở' để mở rộng các mô hình khác của bạn. Nếu nó là rắn và được thử nghiệm tốt, nó có thể làm cho bạn cuộc sống dễ dàng hơn. Đâu là điểm tạo ra các hàm CRUD giống nhau nhiều lần?

Một lợi ích khác của việc đó là bạn có thể có kho lưu trữ phát triển cơ bản mà bạn sao chép để bắt đầu tất cả các dự án mới.

Nếu bạn cần ví dụ về cách thực hiện việc này, hãy xem question Tôi đã hỏi trước đây.

Bạn cũng có thể làm tương tự với số controllers của mình.

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