2008-11-03 42 views
10

Tôi hơi bối rối về cách hoạt động của MVC và tôi không thể tìm thấy bất kỳ điều gì ngoài các ví dụ cơ bản.Cách hiển thị nhiều tiện ích trên cùng một trang bằng cách sử dụng MVC

Tôi muốn tạo ra một loại thiết kế dựa trên tiện ích; bạn có thể chọn các vật dụng khác nhau để đi trên trang của bạn. Mỗi widget phải chịu trách nhiệm cho chính nó - nó cần phải có một bộ điều khiển và một khung nhìn. Nhưng còn về trang chính thì sao? Đột nhiên tôi có một trang với rất nhiều bộ điều khiển trên đó!

Điều hiển nhiên cần làm là nhúng bộ điều khiển trong chế độ xem bằng cách nào đó ... This is my widget {SomeWidget} nhưng tôi đã đọc rằng "phá vỡ mô hình MVC".

Một số tiện ích con cần POST cho các url khác nhau (như hộp tìm kiếm chuyển đến trang kết quả) và một số cần POST trở lại cùng một URL (như thêm nhận xét vào bài viết sẽ đưa bạn trở lại bài viết) .

Để đầu trang vật tắt, người dùng sẽ có thể chỉnh sửa HTML xung quanh các widget - ví dụ nếu họ muốn có một hộp tìm kiếm ở bên phải, họ có thể gõ <div style="float: right;">{SearchController}</div> (trong thế giới mô-breaking của tôi)

Trả lời

2

Tôi không giỏi lập trình web, nhưng tôi tin rằng, từ ví dụ bạn mô tả, cần có một mô hình, một khung nhìn và một bộ điều khiển cho toàn bộ trang. Bây giờ khung nhìn chính nó sẽ chứa các khung nhìn cho mỗi widget trong trang (và giống như vậy với bộ điều khiển trang) mà nó gửi đi các thông điệp mà nó nhận được.

Khái niệm có mức MVC thấp hơn (đối với tiện ích con) và mức MVC cao hơn (đối với trang). Và mô hình MVC sẽ không bị phá vỡ. Bây giờ bạn có thể chỉnh sửa HTML xung quanh tiện ích, nó thay đổi mô hình trang (và không phải bất kỳ mô hình widget nào).

Hy vọng điều này sẽ hữu ích!

+0

Phải thêm mã vào mẫu và lớp không tạo cho tiện ích con và plugin. – rick

+0

Tôi sợ tôi không hiểu bình luận của bạn ... Bạn có thể thuật lại? –

2

Để thêm vào nhận xét của @ Benoît:

Khuôn khổ Symfony xử lý việc này với các thành phần. Mỗi thành phần là một cá thể MVC khép kín có thể được nhúng vào một khung nhìn khác. Nó không thể được khởi tạo để đáp ứng trực tiếp các yêu cầu web như thể hiện MVC bình thường (một cặp mô-đun/hành động). Nó chỉ có thể được nhúng vào một chế độ xem MVC khác.

Lưu ý: Symfony cũng xử lý các plugin như là một cá thể MVC hoàn chỉnh của riêng chúng, hoàn chỉnh với lược đồ, mô hình, bộ điều khiển, tệp cấu hình, khung nhìn, et al.

Trong trường hợp của bạn, mỗi thành phần sẽ là trường hợp MVC của riêng nó và ứng dụng sẽ ghép các thành phần này lại với nhau. Mỗi thành phần sẽ chịu trách nhiệm về cách thức nó phản hồi một biểu mẫu gửi.

MVC không có nghĩa là có MỘT lượt xem và MỘT bộ điều khiển. Nó chỉ có nghĩa là logic ứng dụng được lưu trữ trong các mô hình, bộ điều khiển gắn kết mọi thứ lại với nhau và khung nhìn sẽ hiển thị màn hình. Đó là sự tách biệt chính thức và logic của logic và thuyết trình.

0

Có rất nhiều biến thể về chủ đề MVC và rất nhiều điều cần xem xét trước khi đi đến kết luận về thiết kế của hệ thống cụ thể của bạn. Hầu hết các hệ thống dựa trên web phổ biến mới nhất đều xem xét đến IoC làm nguyên tắc chỉ đạo. Thông thường, một số loại thành phần khung là bộ điều khiển sử dụng một số loại cấu hình để gọi mẫu thích hợp làm dạng xem và ghép nối nó với phân cấp đối tượng thích hợp làm mô hình. Hầu hết các hệ thống này bao gồm một thư viện tiện ích mở rộng GUI được sử dụng bởi các mẫu. Bạn có thể thêm các widget của riêng bạn nhưng nó không phải là thực hành tốt nhất để mã cứng các widget của bạn vào một hệ thống phân cấp đối tượng cụ thể. Liên kết IoC đó cũng nói về các thành phần và dịch vụ sẽ cung cấp cho bạn một số hướng về cách tránh mã hóa cứng đó.

1

Một trong những cuốn sách hay nhất, ngắn và đơn giản, tôi đã tìm thấy trên MVC là một trong những này đưa ra tuần trước tại hội chợ PDC 2008:

http://www.apress.com/book/view/1430216468

Nó không chỉ bao gồm các khái niệm MVC, nhưng so sánh của nó với các khái niệm khác như Ruby on Rails và phương pháp MVP.

Ngoài ra, nó đi vào toàn bộ lý do MVC tồn tại bằng cách mô tả tách mối quan tâm và lý do tại sao nó không chỉ ở cấp UI - mà còn vào lớp thực tế hoặc cấu trúc IoC của các đối tượng kinh doanh của bạn và DAL.

Tôi rất muốn giới thiệu cuốn sách này khi anh ấy trình bày các phương pháp hay nhất, chỉ trong 110 trang hoặc hơn.

Và không, tôi không làm việc cho FirstPress hoặc liên quan đến họ cả. Tôi chỉ thích cuốn sách, và cuối cùng là một người tôi đồng ý.

+0

Cuốn sách này là nhiều hơn về một khung MVC cụ thể (ASP.NET MVC). Tuy nhiên, tôi ít nhất cũng đồng ý rằng nó có một phần tốt đẹp về cách MVC so sánh với các mẫu giao diện người dùng khác. –

+0

Liên kết đó bị mục nát và bạn chưa bao giờ nói tiêu đề của cuốn sách. Bạn đang đề cập đến điều gì? –

0

ASP.NET MVC rất phù hợp với trang loại mashup của trang tổng quan tiện ích.

Hãy xem this phiên từ PDC 2008.

Bạn có thể sẽ muốn sử dụng người giúp Ajax để cập nhật các đảo dữ liệu trong mỗi widget. Dưới đây là một đoạn trích về cách bạn có thể đặt một máy tính trên bất kỳ trang nào nhưng giữ mã độc lập.

Xem Snippet:

<script type="text/javascript"> 
    function OnFailure(error) { 
     alert("We have encounterd an error " + error); 
    } 
</script> 
<% using (Ajax.BeginForm("Add", new AjaxOptions{UpdateTargetId="sum", OnFailure="OnFailure"})){ %> 
    <%= Html.TextBox("x") %>&nbsp;+&nbsp; 
    <%= Html.TextBox("y") %>&nbsp;=&nbsp; 
    <span id="sum">?</span> 
    <input type="submit" value="AddEm" /> 
<% } %> 

khiển Snippet:

[AcceptVerbs(HttpVerbs.Post)] 
public ActionResult Add(string x, string y) 
{ 
    int sum = int.Parse(x) + int.Parse(y);  
    return Content(sum.ToString()); 
} 
+0

Tại sao câu trả lời này lại bị bỏ phiếu? Nếu có lỗi cho tôi biết và tôi sẽ sửa. –

1

Các thông tin tốt nhất mà tôi đã tìm thấy trên làm vật dụng trong ASP.NET MVC là trên blog của Steve Sanderson của. Ông giải thích khái niệm của mình về các yêu cầu một phần là một kỹ thuật khác với các bộ điều khiển phụ.

http://blog.codeville.net/2008/10/14/partial-requests-in-aspnet-mvc/

yêu cầu một phần rất dễ Bạn đã nghe nói về quang cảnh một phần, vậy làm thế nào về yêu cầu một phần? Trong bất kỳ yêu cầu nào của MVC , bạn có thể thiết lập một bộ sưu tập yêu cầu từng phần nội bộ, mỗi yêu cầu có thể thiết lập các yêu cầu một phần nội bộ riêng của mình và cứ thế. Mỗi yêu cầu một phần hiển thị phương thức hành động đơn giản đồng bằng trong bất kỳ bộ điều khiển thông thường nào của bạn và mỗi bộ có thể tạo ra một tiện ích độc lập. Tôi là gọi cho họ một phần “yêu cầu” thay vì so với “bộ điều khiển” vì họ chạy một đường ống xử lý yêu cầu MVC thích hợp với hệ thống định tuyến và nhà máy điều khiển của bạn. Tuy nhiên, như với các điều khoản con, tất cả các điều khiển vẫn còn trong bộ điều khiển và chế độ xem có thể không biết gì.

0

Tôi nghĩ câu trả lời của JarrettV và jcoby là gần nhất.

Tôi đã biết các điều khoản con dưới dạng MCV phân cấp (HMVC). Ý tưởng là bạn "kéo" nội dung (một khung nhìn được điền bởi một bộ điều khiển con) từ mẫu khung nhìn cha mẹ thay vì "đẩy" dữ liệu vào mẫu từ bộ điều khiển. Vì vậy, thay vì cần chỉnh sửa cả bộ điều khiển và chế độ xem để thêm tiện ích, bạn chỉ cần gọi tiện ích từ chế độ xem. Có những thư viện để thực hiện điều này trong các khung công tác php CodeIgniter (Modular Extensions) và Kohana (Dispatch và Component).

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