2008-09-11 34 views
7

Gần đây cảm ơn sự nổi tiếng của đường ray, nhiều người bắt đầu sử dụng activerecord làm người mẫu. tuy nhiên, trước khi tôi nghe về đường ray (nhóm đồng đẳng của tôi không phải là fan của những thứ nguồn mở, chúng tôi được dạy trong một trường học .NET ...) và trong khi tôi đang thực hiện dự án năm cuối, tôi đã tìm thấy định nghĩa này cho một mô hìnhactiverecord làm mô hình, đây có phải là một ý tưởng hay không?

Mô hình thể hiện dữ liệu doanh nghiệp và quy tắc kinh doanh chi phối quyền truy cập và cập nhật dữ liệu này. Thông thường, mô hình này đóng vai trò như một phần mềm xấp xỉ với quy trình thực tế, vì vậy các kỹ thuật mô hình hóa thực tế đơn giản áp dụng khi xác định mô hình.

nó không nói mô hình nên đại diện cho một bảng như activerecord làm gì. Và thông thường trong một giao dịch, người ta có thể phải truy vấn một vài bảng không liên quan và sau đó thao tác dữ liệu từ các bảng khác nhau ... vì vậy nếu activerecord được sử dụng làm mô hình, thì một trong hai sẽ phải nhồi nhét tất cả mã logic vào bộ điều khiển (kinda phổ biến trong một số khuôn khổ php) mà làm cho nó khó khăn để kiểm tra hoặc hack mô hình activerecord để nó thực hiện hoạt động cơ sở dữ liệu trên không chỉ bảng nó bản đồ, mà còn ... Điện thoại

so, what tuyệt vời như thế nào về việc lạm dụng (IMHO) activerecord như mô hình trong một mô hình kiến ​​trúc MVC?

+0

không, đó là ý tưởng cực kỳ tồi. –

Trả lời

8

Martin Fowler mô tả mẫu này trong Các mẫu kiến ​​trúc ứng dụng doanh nghiệp cùng với hai mẫu hoặc kiến ​​trúc khác. Các mẫu này phù hợp cho các tình huống khác nhau và số lượng phức tạp khác nhau.

Nếu bạn chỉ muốn những công cụ đơn giản, bạn có thể sử dụng Tập lệnh giao dịch. Đây là một kiến ​​trúc mà bạn đã thấy trong các trang ASP và PHP cũ, trong đó một tập lệnh duy nhất chứa logic nghiệp vụ, logic truy cập dữ liệu và logic trình bày. Điều này rơi nhanh chóng khi mọi thứ trở nên phức tạp hơn.

Điều tiếp theo bạn có thể làm là thêm một số sự tách biệt giữa bản trình bày và mô hình. Đây là activerecord. Mô hình này vẫn được gắn với cơ sở dữ liệu nhưng bạn đã linh hoạt hơn một chút bởi vì bạn có thể sử dụng lại mô hình/dataccess của mình giữa các khung nhìn/trang/bất kỳ thứ gì. Nó không linh hoạt như nó có thể nhưng tùy thuộc vào giải pháp truy cập dữ liệu của bạn, nó có thể đủ linh hoạt. Các khung như CSLA trong .Net có rất nhiều khía cạnh từ patterm này (tôi nghĩ Entity Framework có vẻ hơi quá nhiều như thế này). Nó vẫn có thể xử lý rất nhiều phức tạp mà không trở thành không thể duy trì.

Bước tiếp theo là tách lớp truy cập dữ liệu và mô hình của bạn. Điều này thường đòi hỏi một người lập bản đồ hay HOẶC rất nhiều công việc. Vì vậy, không phải ai cũng muốn đi theo cách này. Các phương pháp luận của Lot như thiết kế định hướng miền mô tả cách tiếp cận này.

Vì vậy, đó là tất cả vấn đề ngữ cảnh. Bạn cần gì và giải pháp tốt nhất là gì. Tôi thậm chí còn sử dụng giao dịch-kịch bản đôi khi cho mã đơn sử dụng đơn giản.

+0

+1: Đề cập đến Martin Fowler là lý do đủ để thăng hạng bài đăng của bạn. Tôi tin rằng bất kỳ người nào nghĩ về việc lập mô hình ứng dụng nên cố gắng đọc sách và giấy tờ của mình. –

1

Điều tuyệt vời khi sử dụng Rails ActiveRecord làm mô hình trong MVC là nó cung cấp cho bạn một ORM tự động (Object Relational Mapper) và cách dễ dàng để tạo liên kết giữa các mô hình. Như bạn đã chỉ ra, MVC đôi khi có thể thiếu.

Do đó, đối với một số giao dịch phức tạp liên quan đến nhiều mô hình, tôi khuyên bạn nên sử dụng Trình bày giữa bộ điều khiển và mô hình của bạn (Rails Presenter Pattern). Người trình bày sẽ tổng hợp các mô hình của bạn và logic giao dịch và sẽ vẫn dễ dàng kiểm chứng được. Bạn chắc chắn muốn phấn đấu để giữ tất cả logic kinh doanh của bạn trong các mô hình hoặc diễn giả của bạn, và ra khỏi bộ điều khiển của bạn (Skinny Controller, Fat Model).

2

Tôi đã nói nhiều lần rằng việc sử dụng Bản ghi hoạt động (hoặc ORM gần như giống nhau) vì Mô hình kinh doanh không phải là một ý tưởng hay. Hãy để tôi giải thích:

Thực tế là PHP là mã nguồn mở, miễn phí (và tất cả những câu chuyện dài ...) cung cấp cho nó với một cộng đồng rộng lớn các nhà phát triển đổ mã vào diễn đàn, các trang web như GitHub, Google mã và vv. Bạn có thể thấy điều này như là một điều tốt, nhưng đôi khi nó có xu hướng không được "rất tốt". Ví dụ, giả sử bạn đang phải đối mặt với một dự án và bạn muốn sử dụng một framework ORM cho phải đối mặt với vấn đề của bạn viết bằng PHP, cũng ... bạn sẽ có rất nhiều options to choose for:

  • thuyết
  • Propel
  • QCodo
  • sự hôn mê
  • RedBean

và danh sách đi và về. Các dự án mới được tạo thường xuyên. Vì vậy, hãy tưởng tượng rằng bạn đã xây dựng một khuôn khổ thổi đầy đủ và thậm chí một trình tạo mã nguồn dựa trên khuôn khổ đó. Nhưng bạn đã không đặt các lớp kinh doanh bởi vì, sau khi tất cả, "tại sao lại viết cùng một lớp?". Thời gian trôi qua và khung công tác ORM mới được phát hành và bạn muốn chuyển sang ORM mới, nhưng bạn sẽ phải sửa đổi hầu hết mọi ứng dụng khách sử dụng tham chiếu trực tiếp đến mô hình dữ liệu của bạn.

Dòng dưới cùng, Active Record và ORM có nghĩa là nằm trong Lớp dữ liệu của ứng dụng của bạn, nếu bạn trộn chúng với Lớp trình bày của mình, bạn có thể gặp phải các vấn đề như ví dụ này.

Nghe lời nói khôn ngoan của @ Mendelt: Đọc Martin Fowler. Ông đã đặt nhiều sách và bài viết về thiết kế OO và xuất bản một số tài liệu tốt về chủ đề này. Ngoài ra, bạn có thể muốn xem xét Anti-Patterns, cụ thể hơn vào Vendor Lock In, đó là những gì sẽ xảy ra khi chúng tôi làm cho ứng dụng của chúng tôi phụ thuộc vào các công cụ của bên thứ 3. Cuối cùng, tôi đã viết bài đăng trên blog this về cùng một vấn đề, vì vậy nếu bạn muốn, hãy xem nó.

Hy vọng câu trả lời của tôi đã được sử dụng bất kỳ.

+0

cảm ơn cho câu trả lời, trên thực tế bản thân tôi là chỉ đạo đi từ ORM sau khi làm việc với họ trong một thời gian như họ là rất thiếu linh hoạt ở lần. Học được rất nhiều thông qua công việc trong suốt những năm này: D – Jeffrey04

+0

Doctrine 2 hỗ trợ mô hình hóa miền đúng (không giống Doctrine 1) và cho phép thiết kế cơ sở dữ liệu khác với thiết kế mô hình miền của bạn. Tôi đã khá hài lòng với nó cho đến nay. Hãy xem tại đây: http://www.doctrine-project.org/ –

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