Google Chrome và IE8 (trong số những người khác) nhằm mục đích cung cấp độ tin cậy/ổn định cao hơn bằng cách cách ly từng tab (trang web) trong một quy trình riêng biệt (đơn giản hơn, tôi biết).Thiết kế đa tiến trình Chrome/IE8, có thể trong .NET không?
Điều này dường như nặng hơn nhiều sau đó nhiều luồng, nhưng có lợi ích lớn nhất của sự cố trong một quá trình không làm giảm toàn bộ ứng dụng. Có vẻ như kiến trúc nhiều quá trình từ lâu đã được sử dụng trong các ứng dụng phía máy chủ (ví dụ: máy chủ web), nhưng đây là những quá trình không có GUI chuyên dụng. Điều thú vị là nó hiện đang được sử dụng trong giao diện người dùng của các ứng dụng máy tính để bàn.
Tôi sẽ thực hiện điều này như thế nào trong ứng dụng .NET Biểu mẫu Windows? Thậm chí có thể không?
Process.Start() là nơi đầu tiên hiển nhiên, nhưng GUI của quy trình mới không được tích hợp chặt chẽ với GUI của ứng dụng máy chủ lưu trữ. Đây là một ứng dụng độc lập mới, không phải là một điều khiển phụ/cửa sổ của ứng dụng máy chủ, vì nó là với Chrome/IE8.
(Đối với bất cứ ai quan tâm đến Scott Hanselmann đã viết một đoạn giới thiệu tốt để các IE8 multi-process architecture here..)
[Cập nhật]
Cụ thể hơn:
Làm thế nào có thể một "sub-process" riêng biệt làm cho trực tiếp đến giao diện người dùng trong "quy trình chính"? Đây thực sự là những gì đang xảy ra, hoặc như đã được đề xuất trong các bình luận, liệu quá trình con sử dụng IPC để yêu cầu quá trình chính để làm cho nó?
+1, đặc biệt là hãy cẩn thận giao tiếp giữa các lĩnh vực. Điều đó có thể tốn kém hơn nhiều so với các nhà phát triển đôi khi mong đợi. –
Có thể 2 AppDomains trong một quá trình cập nhật giao diện người dùng độc lập, tức là các tab riêng biệt? Ngoài ra, như Scott Hanselmann nói, vẫn có thể làm giảm toàn bộ quá trình từ một AppDomain. – Ash
@Ash giả định một quá trình/AppDomain là quá trình "GUI", chịu trách nhiệm nhận lệnh từ các quy trình khác và phản ánh chúng; và quay trở lại với họ, tại sao không? –