Các phương pháp hay nhất để xây dựng trang Asp.net MVC, cho phép tính song song và hiệu quả là gì?

Question

Tôi thấy khó để tranh luận với bất kỳ điều gì trong phê phán này về khung công tác của ASP.net MVC cho thành phần trang.

http://www.matlus.com/problems-with-asp-net-mvc-framework-design/

Riêng những điểm sau:

• Không truy cập để xem hoặc trường hợp xem phần
• ViewData là bạn loại lỏng lẻo vật mang tin
• điều khiển là không thực sự kiểm soát
• Child Hành động không có ý nghĩa của bối cảnh yêu cầu
• lượt xem được ghép nối với bộ điều khiển

Đối với các ứng dụng nhỏ, tôi không nghĩ rằng rất nhiều trong số này chứng minh là một vấn đề, nhưng trong các ứng dụng lớn nơi bạn muốn sử dụng lại nhiều thành phần được chia sẻ hoặc ngay cả khi bạn chỉ có một ứng dụng lớn phụ thuộc vào nhiều nguồn thông tin phụ trợ để có được tất cả thông tin cần thiết để hiển thị một khung nhìn, nó bắt đầu bị hỏng.

Một nửa giải pháp khác nhau cho những vấn đề này đã được đề xuất nhưng chúng không xuất hiện để mở rộng tốt hoặc có những hạn chế thiết kế không mong muốn.

Dưới đây là một kịch bản ví dụ ứng dụng:

1. 50% nội dung trang là phổ biến trên tất cả các trang trong một ứng dụng (header, footer, menu, vv)
2. Ứng dụng của bạn thực sự có thể được bao gồm nhiều khu vực, mỗi khu vực có bộ điều khiển riêng, vv để phát triển độc lập.
3. Một số yếu tố trang (menu, thông tin tiêu đề trang, chân trang, tiết lộ) nằm trong nội dung trang chung yêu cầu một hoặc nhiều cuộc gọi dịch vụ để điền dữ liệu để hiển thị.

Được rồi, vì vậy trong asp.net mvc3, giả sử bạn quyết định rằng bạn muốn chia sẻ bố cục Dao cạo phổ biến chứa 50% đánh dấu UI phổ biến. Điều này giúp tách biệt các mối quan tâm trong các nhà phát triển ứng dụng không cần phải quan tâm đến ui phổ biến và có thể tập trung vào logic và quan điểm cụ thể cho lĩnh vực chuyên môn của họ.

Tuy nhiên, điều này hoàn toàn bị hỏng trong trường hợp bố cục được chia sẻ này cần dữ liệu (một số ngữ nghĩa của một hoặc nhiều kiểu mô hình) để tự hoàn thành. Bạn có thể có yếu tố độc lập trên trang mà mỗi cần một mô hình dữ liệu cụ thể, chẳng hạn như: * Menu chính mô hình * mô hình trình đơn thứ * liên kết chân trang mô hình * mô hình cho phép * chân kỹ khuyến cáo mô hình

Và mỗi người trong các mô hình này có thể có các nguồn riêng biệt. Vì vậy, mặc dù bạn có thể chia sẻ mẫu, không có cách nào dễ dàng để chia sẻ logic để xây dựng từng mô hình này - và chắc chắn không phải là một mẫu chung chung, có thể mở rộng và hiệu suất mà tôi đã thấy.

Một số phương pháp cho vấn đề này mà tôi đã thấy là:

• mạnh gõ bố trí chung, đòi hỏi tất cả các mô hình điểm để phân lớp một lớp mô hình cơ sở chung. (nhưng không có giải pháp chung để phổ biến mô hình meta như vậy và điều này đang hạn chế trong thiết kế và làm cho các mô hình trở nên lớn hơn và khó kiểm tra hơn) Ngoài ra, dân số mô hình vẫn rơi vào mọi bộ điều khiển, vi phạm Tách mối quan tâm và Nguyên tắc trách nhiệm duy nhất và các bộ điều khiển thử nghiệm đơn vị phức tạp bằng cách chồng chất lên nhiều lôgic phụ để đưa vào mô hình meta ngoài thông tin mô hình cụ thể của khung nhìn.
• Để bố cục chung không được nhập, vì vậy bạn không phải kế thừa từ mô hình cơ sở chung, nhưng điều này yêu cầu bạn sử dụng ViewData hoặc ViewBag để giao tiếp tất cả các mô hình khác nhau mà mẫu cần. lợi ích và kết thúc với một hợp đồng dữ liệu lỏng lẻo. Bạn vẫn có vấn đề thiếu một giải pháp chung để điền vào siêu mô hình và tất cả những gì đi cùng với điều đó.
• Mọi bộ điều khiển phải phân lớp lớp điều khiển cơ sở chung để hỗ trợ bố cục và mô hình chung. Logic để xây dựng các khía cạnh phổ biến của siêu mô hình ở đây. Nhưng điều này không phải lúc nào cũng là một hạn chế về kiến ​​trúc hay thiết kế mong muốn. Điều này ít nhất là giải quyết vấn đề Tách mối quan tâm.
• Thay vì sử dụng mô hình meta, sử dụng hành động con thông qua RenderAction() trong bố cục chung của bạn để tạo các tiện ích kiểu "portlet" có thể sử dụng lại mà mỗi người biết độc lập cách xây dựng mô hình dữ liệu của mình và cung cấp cho họ. Điều này thực sự tốt cho việc phân tách các mối quan tâm, nhưng có một số nhược điểm riêng: quan điểm thực hiện các cuộc gọi dịch vụ một cách hiệu quả trong quá trình render thông qua các hành động con, hành động của trẻ hoàn toàn không biết về bối cảnh yêu cầu ban đầu, vi phạm nguyên tắc DRY vì mỗi hành động con không biết những gì đã đi trước khi nó có thể làm cho cùng một cuộc gọi dịch vụ lặp lại trong cùng một yêu cầu http và các yêu cầu khác. Hãy tưởng tượng 20-30 yếu tố của một trang mà tất cả những gì cần thiết để gọi RenderAction() một cách độc lập ...

Có những trường hợp bổ sung (một số được xem trên stackoverflow), nơi có các vấn đề khác với RenderAction() làm giải pháp . ví dụ. thực tế là việc phát hành nhiều cuộc gọi RenderAction() trong một kết quả vòng lặp trong việc thực thi nối tiếp tất cả các phương thức điều khiển đó. Không có cơ hội cho song song với RenderAction(). Các cuộc gọi dịch vụ bị ràng buộc I/O trong mỗi hành động điều khiển con gây ra toàn bộ quá trình kết xuất chờ I/O. Một bộ điều khiển chỉ có kiến ​​thức về chế độ xem và mô hình trực tiếp của nó và không có gì có một bức tranh hoàn chỉnh về những gì sẽ ở bên trong khung nhìn để song song một số hoạt động.

Tác giả của phê bình trên đã phát triển một mô hình giao diện người dùng khác trên ASP.Net mvc được gọi là Quartz cho phép Bộ điều khiển Thiên Chúa có kiến ​​thức thân mật về chế độ xem và có thể trao cho mỗi người một mô hình xem để có cơ hội song song các cuộc gọi dịch vụ ở vị trí trung tâm để xây dựng các mô hình xem đó. Tôi không biết nếu đây là thiết kế tốt nhất để cung cấp móc để khắc phục các vấn đề nhưng có vẻ đầy hứa hẹn.

Câu hỏi của tôi là, cách tốt nhất để xây dựng một ứng dụng phức tạp trên ASP.Net MVC giúp giải quyết những vấn đề này một cách rõ ràng là gì? Tôi đã nghĩ về một vài khả năng (mặc dù không ai có thể thực tế trong ASP.Net MVC - đó là TBD) nhưng người khác phải đã chạy vào điều này rồi. Các mẫu thiết kế trong ASP.Net MVC hoặc những gì đang đi xuống pike mà có thể làm cho một vấn đề này có thể xử lý?

Answer 1

Tôi không chắc chắn có nhiều hơn nữa tôi có thể đóng góp cho "câu hỏi" này. Tôi nghĩ rằng bạn có một sự hiểu biết tốt về các vấn đề và giải pháp, lợi thế và bất lợi.

Trong ứng dụng tôi hiện đang làm việc, chúng tôi sử dụng một vài phương pháp này bằng cách có cả đối tượng mô hình cơ sở cũng như bộ điều khiển cơ sở. Để giảm thiểu các vòng lặp, chúng tôi lưu trữ một số dữ liệu trong phiên và điền lại trong mô hình bằng cách ghi đè OnActionExecuted trong bộ điều khiển cơ sở và lấy mô hình ra khỏi ngữ cảnh và đặt thuộc tính ra khỏi phiên.

Tôi chắc chắn cũng muốn nghe bất kỳ giải pháp tuyệt vời nào, nhưng tôi nghĩ đây chỉ là những sự cân bằng để giải quyết.

Answer 2

Cá nhân, tôi nghĩ rằng lợi thế của việc sử dụng Hành động con thông qua RenderAction vượt quá những bất lợi.

Bạn có thể tạo các phần tử 'widget' và kết hợp logic của chúng trong hành động điều khiển - theo cách này, chế độ xem của tiện ích con có thể vẫn còn thiếu hiểu biết về Hành động trẻ em đang hoạt động và cách thực hiện để chia tách mối quan tâm tốt đẹp.

Bạn đã nêu chi tiết những nhược điểm của cách tiếp cận này, tuy nhiên tôi nghĩ rằng tác động tiêu cực có thể được giảm thiểu với chiến lược bộ nhớ đệm hợp lý.