2010-03-31 28 views
10

Tôi biết câu hỏi tương tự đã được trả lời trước đây - chẳng hạn như:Đường ray: Bộ điều khiển Skinny so với Mô hình chất béo, hoặc tôi có nên làm cho Bộ điều khiển của tôi bị Anorexic không?

  • đâu logic nên đi
  • nơi để làm nhiệm vụ nhất định, vv

Nhưng tôi có một câu hỏi cụ thể hơn - Làm thế nào xa tôi nên dùng tiên đề này: giữ cho bộ điều khiển của bạn gầy, làm cho chất béo mô hình của bạn!

Dưới đây là một ví dụ:

Ví dụ giả sử tôi có nhiều nguồn dữ liệu xác minh. Một ví dụ tốt sẽ là số VIN - Tôi có thể xác minh nó, nguồn dữ liệu của nhà sản xuất, nguồn dữ liệu của DMV, cũng như cơ sở dữ liệu cục bộ của tôi - để xem những gì tôi có trong hồ sơ. Vì vậy, tôi có một mô hình được gọi là Vin và vins_controller. Bên trong mô hình tôi có 5 phương pháp:

  • check_against_local_db
  • check_against_dmv
  • check_against_car_maker_1
  • check_against_car_maker_2 vv

Trong điều khiển của tôi phù hợp với REST, trong chương trình hành động - Tôi có một câu lệnh case đơn giản xem xét các params [: source], và dựa trên nguồn được chỉ định - sẽ gọi phương thức kiểm tra cụ thể.

Bây giờ, đây là câu hỏi: Tôi có nên rời khỏi logic điều chỉnh nguồn dữ liệu để gọi trong bộ điều khiển hay tôi chuyển nó sang mô hình và sau đó trong bộ điều khiển chỉ cần thực hiện điều gì đó như check_vin (nguồn, vin)?

Tôi có nên làm cho bộ điều khiển của tôi gây độc không?

EDIT

Tôi đang chuyển đổi này để trả lời chính thức từ @ jay-Godse (cảm ơn bạn - vào thời điểm đó nó là một câu trả lời tốt). Mọi thứ đã thay đổi rất nhiều kể từ năm 2010 và câu hỏi này vẫn nhận được một số lượt xem - vì vậy hy vọng điều này sẽ hướng một số người đi đúng hướng và giúp họ tổ chức mã của họ đúng cách.

Trailblazer gem giải quyết các vấn đề nảy sinh trong câu hỏi thực sự tốt.

Trả lời

2

Bạn nên cung cấp Trailblazer một lần. Đây là một khung làm việc mỏng trên Rails (trên thực tế, nó chạy với tất cả các khung công tác Ruby), nó giới thiệu một lớp dịch vụ, các đối tượng biểu mẫu, sự khác nhau giữa sự tồn tại và mã miền, v.v.

Nó thực sự giúp giữ cho tất cả các thành phần phần mềm của bạn gầy vì nó cung cấp cho bạn nhiều lớp trừu tượng hơn giúp dễ dàng tìm ra vị trí đặt cái gì.

Ví dụ: tại sao bạn sẽ nhấn logic xác thực của mình vào bộ điều khiển và mô hình khi bạn có đối tượng biểu mẫu cho điều đó?

+1

Tôi đang chuyển điều này thành câu trả lời chính thức. Mọi thứ đã thay đổi rất nhiều kể từ năm 2010 và câu hỏi này vẫn nhận được một số quan điểm - vì vậy hy vọng điều này sẽ chỉ ra một số người đi đúng hướng. Trailblazer giải quyết các vấn đề nảy sinh trong câu hỏi thực sự tốt. – konung

4

Tôi sẽ đặt logic vào mô hình của mình, đặc biệt nếu tôi là TDD'ing (và tôi luôn TDD, trừ khi không.) Kiểm tra mô hình thường dễ dàng hơn nhiều so với kiểm tra bộ điều khiển.

+0

Điều này cũng có nghĩa là bạn không cần phải xác thực trong mỗi bộ điều khiển của mình. – SeanJA

3

Tôi muốn tiếp cận các câu hỏi như thế này bằng cách suy nghĩ về trách nhiệm. Điều gì trong trường hợp này là "chịu trách nhiệm" để xác minh VIN? Ngươi mâu. Bộ điều khiển chỉ đơn giản là có để vượt qua các thông số ... để "điều khiển" dựa trên đầu vào của người dùng.

Nếu nó không hoàn toàn rõ ràng, hãy nghĩ theo cách này: nơi sẽ đặt mã này gây ra tác động ít nhất nếu nó cần được tái sử dụng? Nói ... nếu hai hành động khác nhau trong hai bộ điều khiển khác nhau, cả hai cần phải xác minh một VIN, những gì sẽ cần phải được thực hiện?Nếu bạn để lại mã này trong bộ điều khiển, về cơ bản bạn phải sao chép nó trong bộ điều khiển mới, nhưng nếu bạn đã đặt nó trong mô hình, bạn chỉ cần gọi phương thức check_vin từ bộ điều khiển mới và không có mã nào trùng lặp là cần thiết. Bằng cách chỉ định trách nhiệm nơi chúng có ý nghĩa nhất, bạn đã cải thiện khả năng sử dụng lại mã của bạn.

+0

Tôi thích nói "Mã điều khiển dành cho khách hàng HTTP" ... nếu bạn (giả định) sử dụng lại mô hình trong ứng dụng dành cho máy tính để bàn thì sao? Điều đó thường làm thẳng ra nơi mã nên đi. –

19

Có một câu nói cũ,

thông minh cấu trúc dữ liệu và mã câm hoạt động tốt hơn rất nhiều so với cách khác xung quanh.

Mọi thứ bạn đã mô tả là về cách một phần dữ liệu liên quan đến một phần dữ liệu khác. Đó chính là manh mối của bạn rằng logic cho các mối quan hệ đó, bao gồm việc xác nhận hợp lệ phải ở trong mô hình hoặc lớp cơ sở dữ liệu.

Bộ điều khiển độc hại là dấu hiệu của dữ liệu được thiết kế tốt (thông minh?). Kinh nghiệm của tôi cho tôi biết rằng bạn càng nỗ lực nhiều hơn trong việc thiết kế dữ liệu của mình, bạn càng phải viết ít mã hơn.

Bộ điều khiển tốt nhất khi phân tích đầu vào, gọi các mô hình thích hợp và sau đó định dạng đầu ra.

+0

Rất thú vị. Tôi rất vui vì đã đọc điều này ... và cũng đã tìm kiếm nguồn gốc của câu nói đó: [Nhà thờ và chợ] (http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) – dmonopoly

+0

+1 cho " * Bộ điều khiển tốt nhất khi phân tích đầu vào, gọi các mô hình thích hợp và sau đó định dạng các đầu ra. * " – Ish

2

Trách nhiệm của bộ điều khiển là "phân tích cú pháp" params, nhưng việc xác thực phải được thực hiện trong mô hình.

tôi sẽ làm một cái gì đó như thế này trên bộ điều khiển:

@my_model = MyModel.new(:source => params[:source] ...) 
if(@my_model.valid?) 
    # treat valid model here (i.e. save the model and redirect to show) 
else 
    # treat validation error here (usually throw an error) 
end 

điều khiển của bạn sẽ thực sự được chỉ là "gầy". Đối với bộ điều khiển "anorexic" thực sự, bạn có thể muốn xem inherited_resources hoặc resource_this. Trong một số trường hợp, chúng sẽ cung cấp cho bạn bộ điều khiển 3 dòng, triển khai toàn bộ ngăn xếp RESTful.

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