.NET Remoting có thực sự không được dùng nữa không?

95

Mọi người đang nói làm thế nào .NET Remoting đang được thay thế bằng WCF, nhưng tôi đang tự hỏi mức độ chính xác của điều đó. Tôi chưa thấy bất kỳ từ chính thức nào nói rằng Remoting không được dùng nữa, và có vẻ như với tôi chắc chắn có những trường hợp mà Remoting có ý nghĩa hơn WCF. Không có đối tượng hoặc phương pháp nào liên quan đến Điều khiển từ xa không được dùng nữa, ngay cả trong phiên bản 4.0 của khung. Tôi cũng hiểu rằng System.AddIn trong các khung 3.5 và 4.0 sử dụng tính năng Điều khiển từ xa.

Có ai có bất kỳ từ chính thức để trái ngược?

Trong bài viết Chọn Tùy chọn Giao tiếp trong .NET (dành cho 3.0, vì đó là phiên bản mới nhất của bài viết đó), nó nêu rõ:

8 Truyền thông miền ứng dụng chéo

Nếu bạn cần hỗ trợ giao tiếp giữa các đối tượng trong các miền ứng dụng khác nhau trong cùng một quy trình, bạn phải sử dụng .NET remoting.

Tất nhiên, điều đó không chính xác vì WCF chắc chắn có thể được sử dụng để vượt qua ranh giới tên miền ứng dụng, nhưng liệu nó có đưa ra khuyến nghị chính thức cho trường hợp đó không?

Cập nhật: Tôi đã gửi cho Clemens Vasters (người trong nhóm sở hữu Remoting và WCF) câu hỏi này:

Clemens, tôi hiểu bạn đang ở trong nhóm sở hữu cả remoting và wcf, và tôi có một vài câu hỏi mà tôi tin rằng tôi cần phải truy cập nguồn.

Đầu tiên, tôi có một câu hỏi về việc liệu sự hối hận có biến mất hay không. Cụ thể, chúng tôi có một ứng dụng khá lớn sử dụng Removing rộng rãi cho giao tiếp giữa các tên miền ứng dụng trong quá trình và tôi đã tự hỏi liệu việc sử dụng remoting này có được coi là "di sản" hay không. Nếu vậy, AppDomain.CreateInstance và bạn bè có được thay thế bằng thứ khác không?

Đây là câu trả lời của anh ấy:

Điều khiển từ xa là một phần của .Net Framework và như vậy nó sẽ không biến mất. COM đã có trong Windows kể từ Windows NT 3.5 / Windows 95 và vẫn chưa biến mất và tôi cũng không thấy điều đó sẽ sớm biến mất.

Điều đó nói rằng, có rất ít đầu tư phát triển vào Remoting. WCF là sự kế thừa của Remoting và bổ sung COM / DCOM cho mã được quản lý.

Đối với giao tiếp trong quá trình, giữa các tên miền ứng dụng Từ xa là cách giao tiếp tự nhiên của CLR. Nếu bạn thấy các vấn đề về hiệu suất khi bơm lượng dữ liệu lớn hơn hoặc rất nhiều thông báo trong thời gian ngắn, bạn nên xem xét nghiêm túc WCF và NetNamedPipeBinding.

.net wcf remoting

— dấu
nguồn

1

Xem stackoverflow.com/questions/1295353/… để có câu hỏi về lý do tại sao WCF lại chậm hơn nhiều so với Khởi động trong tình huống cụ thể của tôi.

— Đánh dấu

1

Điều khiển từ xa là bản chất của .NET và thông tin chi tiết về vai trò của nó cũng như cách hoạt động của nó có thể được tìm thấy trong Essential .NET của Don Box và Chris Sells. Tuy nhiên, nó sẽ bị phá vỡ khi liên lạc giữa các thành phần không đáng tin cậy hoặc chậm, và thực tế tất cả các quá trình truyền tải - ngay cả một mạng LAN gigabit - đều không đáng tin cậy và chậm so với nhắn tin trong quá trình. Khi mọi người nói về WCF chậm, họ thường nghĩ đến các dịch vụ web. Dịch vụ Web là quá chậm nếu bạn cố gắng sử dụng chúng cho vệ tinh viễn thông trong quá trình. Tuy nhiên, chúng được thiết kế để chịu được các kết nối chậm và không đáng tin cậy cũng như hoạt động tốt trong những điều kiện này.

— Peter Wone

3

@Peter: cảm ơn vì thông tin, nhưng một vài giả định của bạn là hoàn toàn sai. Một, sự hối hận đó diễn ra chậm hoặc không đáng tin cậy. Nó không thể. Nó rất nhanh và rất đáng tin cậy (tất nhiên là qua các kênh đáng tin cậy). Khác là "dịch vụ web" (bất kể điều đó có nghĩa là gì) chậm. Không phải vậy. Tất nhiên, bất cứ điều gì trong quá trình sẽ là nhanh hơn nhiều so với bất cứ điều gì trên mạng, nhưng đó không phải ở tất cả những gì câu hỏi này là về ...

— Đánh dấu

54

Gọi nó là một công nghệ kế thừa là một mô tả chính xác hơn.

http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx

Chủ đề này dành riêng cho một công nghệ kế thừa được giữ lại để tương thích ngược với các ứng dụng hiện có và không được khuyến nghị để phát triển mới. Các ứng dụng phân tán bây giờ nên được phát triển bằng Windows Communication Foundation (WCF).

Cập nhật: WCF không phân biệt giữa tên miền inter / intra / process / inter / intra-app. Nếu bạn đang sử dụng giao tiếp máy đơn trong WCF, bạn sử dụng các đường ống được đặt tên - sử dụng nó sẽ cho hiệu suất tốt trong hầu hết các tình huống thực tế.

Để biết so sánh hiệu suất của các công nghệ truyền thông phân tán khác nhau, hãy xem tại đây .

— RichardOD
nguồn

Đó không phải là bài viết đề cập cụ thể đến việc sử dụng từ khóa trong giao tiếp liên quy trình sao? Đối với tôi, dường như sự hối hận vẫn có một vị trí trong giao tiếp giữa các miền ứng dụng (AppDomain.CreateInstanceFromAndUnwrap và bạn bè).

— Đánh dấu

Vâng, đúng vậy. Nếu các lớp này "không được dùng nữa", thì chúng sẽ có Thuộc tính lỗi thời được áp dụng cho chúng- msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .

— RichardOD

2

@Mark, @RichardOD: Bài báo này là bài viết chính trên .NET Remoting. Nó không chỉ đề cập đến giao tiếp giữa các quá trình. Ngoài ra, thực tế là ObsoleteAttribute không có trên chúng trong .NET 3.5 không có nghĩa lý gì, vì quyết định công bố Remoting (và các dịch vụ web ASMX) là "kế thừa" đã được đưa ra sau .NET 3.5 RTM.

— John Saunders

@John: Chúng cũng không được đánh dấu là [Lỗi thời] trong 4.0 (ít nhất là chưa).

— Đánh dấu

@Mark: ý bạn là 4.0 beta 1

— John Saunders

11

Đúng. Tính năng điều khiển từ xa không được dùng nữa ... và nó chính thức từ Microsoft. Đây là liên kết:

.NET Remoting

Dòng đầu tiên trong bài viết in đậm:

Chủ đề này dành riêng cho một công nghệ kế thừa được giữ lại để tương thích ngược với các ứng dụng hiện có và không được khuyến nghị để phát triển mới. Các ứng dụng phân tán bây giờ nên được phát triển bằng Windows Communication Foundation (WCF).

Tôi nghĩ rằng verbiage đã 'không được dùng nữa' nhưng rõ ràng họ gọi nó là 'di sản'

— Justin Niessner
nguồn

21

IMO 'không được dùng nữa' mạnh hơn 'cũ': 'kế thừa' có nghĩa là "không bắt đầu" và không dùng nữa có nghĩa là "nếu bạn đã bắt đầu, hãy dừng ngay bây giờ, vì nó có thể bị xóa hoàn toàn trong các phiên bản tương lai".

— ChrisW

1

@Mark: Tôi không đọc nó theo cách đó. WCF dường như áp dụng cho giao tiếp nội bộ cũng như Remoting (xem NetNamedPipeBinding trong WCF).

— Michael Petrotta

1

@Mark: Bất kể, tính năng Điều khiển từ xa không được dùng nữa. @ChrisW: Tôi nghi ngờ rằng tính năng Điều khiển từ xa sẽ bị xóa trong thời gian tới, nhưng bạn có thể mong đợi ít bản sửa lỗi hơn, nếu có và ít hỗ trợ hơn, nếu có.

— John Saunders

1

@Mark - câu hỏi thực sự của bạn là gì? Remoting được coi là công nghệ kế thừa. Có vẻ như bạn không muốn điều đó thành sự thật. Bạn có thể có những lý do chính đáng, nhưng điều đó không thực sự phù hợp với các khuyến nghị hiện tại của Microsoft.

— Michael Petrotta

1

@John: Tôi đoán là tôi. Tôi đặc biệt đang thực hiện giao tiếp giữa các miền ứng dụng trong quá trình (sử dụng AppDomain.CreateInstanceFromAndUnwrap và bạn bè) và tôi không thấy cách nào để thực hiện điều này một cách rõ ràng (hoặc hiệu suất cao) bằng WCF. Tôi rất vui khi sử dụng WCF thay thế (tôi sử dụng nó rất nhiều trong các tình huống khác), nhưng đối với điều này, tôi gặp khó khăn khi làm cho nó hoạt động theo cách tôi muốn. Tôi sẽ đăng một câu hỏi khác về kịch bản cụ thể đó.

— Đánh dấu

6

Nếu bạn muốn chuyển sang .NET Core, bạn vẫn phải tìm một giải pháp khác để lấy lại từ xa:

.NET Remoting được xác định là một kiến trúc có vấn đề. Nó được sử dụng cho giao tiếp giữa các AppDomain, không còn được hỗ trợ. Ngoài ra, Remoting yêu cầu hỗ trợ thời gian chạy, điều này rất tốn kém để duy trì. Vì những lý do này, .NET Remoting không được hỗ trợ trên .NET Core và chúng tôi không có kế hoạch bổ sung hỗ trợ cho nó trong tương lai.

Nguồn: https://docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting

— Jean-Claude
nguồn

1

Tại đây, bạn có thể tìm thấy cuộc thảo luận về những lựa chọn thay thế nào có sẵn trong .NET Core: github.com/dotnet/corefx/issues/18394

— Jean-Claude

Cũng được đề cập ở đây: docs.microsoft.com/en-us/dotnet/core/porting/…

— Jean-Claude

2

Clemens Vasters, Trưởng nhóm kỹ thuật của Microsoft .NET Service Bus (có nghĩa là cả Remoting cũng như WCF) nói về WCF so với Remoting trong bài đăng trên diễn đàn này . Để tóm tắt bài đăng, anh ấy đã giới thiệu WCF thay vì Remoting.

Tôi không chắc liệu .NET 4.0 có sử dụng tính năng gỡ bỏ nội bộ hay không nhưng bạn có thể thử gửi câu hỏi cho Clemens ... Tôi chắc rằng anh ấy biết câu trả lời.

— JohannesH
nguồn

11

Một nhân viên của Microsoft khuyên bạn nên sử dụng phương pháp sáng bóng-mới-không tương thích-với-mọi thứ-khác trên bất kỳ hình thức tiêu chuẩn nào? Gây sốc.

— quillbreaker

14

WCF không tương thích với mọi thứ khác theo cách nào? Và Remoting tương thích với những gì?

— John Saunders

2

Nếu bạn đang tìm kiếm khả năng tương thích, WCF là lựa chọn -chỉ- (tất nhiên là ngoại trừ asmx, nhưng đó cũng là "di sản"). Điều khiển từ xa-bất cứ khi nào- phù hợp với các tình huống yêu cầu khả năng tương thích.

— Đánh dấu

3

Tôi đã gợi ý của bạn và hỏi Clemens. Câu trả lời của anh ấy: "Remoting là một phần của .Net Framework và như vậy, nó sẽ không biến mất ... Đối với giao tiếp trong quá trình, giữa nhiều miền ứng dụng Remoting là cách giao tiếp cơ bản của CLR."

— Đánh dấu

1

Anh ấy tiếp tục nói rằng bạn nên "xem xét nghiêm túc WCF và NetNamedPipeBinding."

— John Saunders

2

Tôi nghĩ rằng bây giờ (2015) nó khá rõ ràng ngay cả đối với các miền ứng dụng chéo: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Remoting Cross AppDomains Chủ đề này dành riêng cho một công nghệ kế thừa được giữ lại để tương thích ngược với các ứng dụng hiện có và không được khuyến nghị để phát triển mới. Các ứng dụng phân tán bây giờ nên được phát triển bằng Windows Communication Foundation (WCF).

Sau đó WCF cũng nên được sử dụng cho các miền ứng dụng chéo.

— Armando
nguồn