2013-05-09 27 views
18

Chúng tôi đang xây dựng các ứng dụng có Mô hình không phải là thành phần cơ sở dữ liệu. Chúng tôi rất tò mò muốn biết những gì người khác đang làm trong cộng đồng đường ray để giải quyết vấn đề này.Đường ray - Vị trí (thư mục) đặt Mô hình không phải là Bản ghi Hoạt động

Chúng tôi đang vật lộn với vị trí đặt chúng.

Chúng ta có nên có:

app/models/domain 

hoặc

app/domain/models 

hoặc có lẽ

app/models # Business Models 
app/models/ar # Active Record Models 

hoặc có lẽ

app/models/domain/ # Business Models 
app/models/domain/ar # Active Record Models 

Một phần của điều này là chúng ta đang đấu tranh với mức độ gần gũi với các tiêu chuẩn đường ray và bao nhiêu để tạo ra một cấu trúc sẽ tốt cho những gì chúng ta cần.

Nếu chúng ta nghĩ về các đối tượng như các đối tượng dịch vụ, chúng tôi có thể có

app/models/service-object 

app/models/ # For plain active record 

tuyến đường khác để đi xuống không có công cụ trong ứng dụng, ví dụ

/service_objects 

thay vì

/app/models/service_objects 

Có lẽ nếu chúng ta muốn truy cập thông qua một ứng dụng ray chúng tôi tốt hơn của việc sử dụng ứng dụng/để tận dụng lợi thế của quy ước về cấu hình.

+5

Thư mục này được gọi là "mô hình". Nó không được gọi là "hậu duệ active_record chỉ". Tôi chỉ cần đặt chúng lại với nhau và ném mô hình Mongoid lên trên :) –

+0

Bạn có thể đặt chúng dưới 'lib' nếu bạn thực sự muốn gắn với AR chỉ trong các mô hình – Raindal

+1

Tôi muốn xem xét lại việc gắn chúng trong' lib' nhưng nó vẫn là một tùy chọn . Tôi thích dán các tập tin trong lib mà tôi muốn xem xét các ứng cử viên tốt cho giải nén vào đá quý để tái sử dụng. –

Trả lời

12

Theo kinh nghiệm của tôi, việc phân chia nơi bạn đặt các mô hình này đi xuống đến những gì chúng thể hiện chức năng trong ngữ cảnh cụ thể của ứng dụng của bạn.

Tôi thường đặt trước app/models cho các mô hình dựa trên tài nguyên. Nếu mô hình đó đại diện cho một tài nguyên được khởi tạo và thao tác bởi ứng dụng của bạn, nó sẽ xuất hiện ở đây. Không cần phải được hỗ trợ AR hoặc db.

Nếu mô hình phân phối chức năng nhất quán nhưng thay đổi theo thông số, tôi cung cấp cho họ một thư mục cấp cao nhất trong ứng dụng. Chẳng hạn như app/mailersapp/observers vv Tuy nhiên, nếu bạn có một tài nguyên yêu cầu người quan sát, có thể không có ý nghĩa để có một thư mục app/observers chỉ với một tệp trong đó.

Mọi thứ khác đi vào lib. Có một vài lý do tại sao điều này là thích hợp hơn.

  1. Bạn có thể chọn thời điểm yêu cầu tệp trong lib. Bạn có thể chọn lọc nhiều hơn về các tệp được tải khi ứng dụng của bạn bắt đầu. Nếu bạn đặt mọi thứ vào app/models bạn không có chi tiết về những gì được tải.

  2. Đặt tên cho các mẫu của bạn khi ứng dụng của bạn phát triển dễ dàng hơn trong lib. Chắc chắn bạn có thể không gian tên trong app/models nhưng một số lớp làm tổ trong app/models luôn luôn kết thúc lên khó chịu. Tốt nhất là giữ cho không gian tên trong lib.

  3. Việc dọn dẹp được thực hiện dễ dàng hơn nhiều khi bạn có mọi thứ ở đúng vị trí chính xác của chúng. Nó không phải là một nguồn tài nguyên? Nó không phải là một người quan sát? Phải ở trong lib. Toàn bộ lý do bạn đưa suy nghĩ vào mặt trận này là cung cấp khả năng phát hiện cho các nhà phát triển xuống dòng.

14

Đối với các đối tượng dịch vụ, bạn thường sẽ có chúng trực tiếp trong thư mục ứng dụng app/services/. Công nhân và người theo dõi cũng tuân theo mẫu này app/workers/app/serializers/. Đối với các mô hình của bạn mà không phải là AR bạn vẫn có thể dính chúng trong thư mục mô hình. Đó là chỉ là của tôi về nó.

+0

+1 Điều đó hữu ích, cảm ơn. Chúng ta có một chút lo ngại rằng khi ứng dụng phát triển, chúng ta có thể kết thúc với 34 mô hình Active Record và 12 mô hình Record không hoạt động và sau đó các mô hình sẽ có mash-mash 46 với nhau. Điều đó có thể được, chúng tôi chỉ tự hỏi về tương lai tiềm năng đó. –

+2

Đồng ý với điều này - tại một thời điểm nhất định, nếu bạn có các mô hình không phải AR ổn định phù hợp với các chức năng cụ thể, bạn luôn có thể trích xuất chúng thành Mô-đun. – mikeryz

+0

Vâng, nó cũng đi xuống để tách mối quan tâm của các ứng dụng. Bạn không muốn một ứng dụng đơn lẻ trở nên lớn đến nỗi bạn không thể quản lý nó. Ví dụ: khi một ứng dụng quá lớn, tôi sẽ xem xét tách auth thành ứng dụng của riêng nó và làm theo mẫu đó sau đó chỉ giao tiếp thông qua API. –

1

Nếu bạn có các lớp học không phải là mô hình, ví dụ họ có thể đại diện cho một hình thức, tôi muốn nói đi trước và đặt chúng trong lib.

Nếu chúng trực giao với ứng dụng của bạn, tức là: một số giao diện được sử dụng để gọi một ứng dụng khác, bạn có thể bọc nó thành đá quý tư nhân hoặc công cộng tùy thuộc vào khả năng áp dụng cho phần còn lại của cộng đồng.

Cuối cùng, nó không thực sự quan trọng. Chọn một thứ và đồng ý với phần còn lại của nhóm của bạn. Di chuyển mọi thứ xung quanh sẽ khá dễ dàng, đặc biệt nếu bạn thêm bất kỳ điều gì bạn quyết định sử dụng vào đường dẫn tải cho ứng dụng của bạn ($LOAD_PATH += '...').

9

Nếu là mô hình, bạn nên đặt chúng vào app/models vì thư mục này chỉ dành cho các mô hình chứ không phải chỉ các lớp con ActiveRecord.

+0

hoạt động tốt, tôi đã làm điều này với đường ray 5 –

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