Lợi thế của việc sử dụng COM trên một DLL đơn giản là gì?

Question

Giả sử rằng bạn chỉ làm việc trong thế giới C++ (không cần interop ngôn ngữ chéo). Lợi ích/sự bất tiện nào bạn thấy khi sử dụng COM thay vì một DLL cơ bản đơn giản? Bạn có nghĩ rằng việc sử dụng COM có đáng giá không nếu bạn không sử dụng giao diện từ các ngôn ngữ khác nhau?

Answer 1

COM có thể hữu ích trong đồng bằng cũ C++ cho: giao tiếp

• Interprocess
• kiến ​​trúc Plugin
• kịch bản trễ ràng buộc
• "Nhiều, nhiều, nhiều hơn nữa ..." (tm)

Điều đó nói rằng, nếu bạn không cần, đừng sử dụng.

Answer 2

• đăng ký và khám phá
• Out-of-process
• từ xa gọi

là vài tính năng bổ sung mà bạn sẽ có được. Ngay cả hỗ trợ giao dịch có thể chảy mà không cần hỗ trợ COM trong những ngày này.

Answer 3

Giao diện IUnknown là cấp cơ sở tốt để hỗ trợ dù sao - giúp bạn thêm các tính năng mà không làm hỏng các ứng dụng khách cũ (QueryInterface) và tính tham chiếu phổ biến. Bạn có thể thực hiện điều này mà không cần mua vào tất cả mọi thứ trong COM. Sau đó, bất cứ khi nào bạn thêm một tính năng vào một lớp, nếu bạn sử dụng giao diện COM cho nó, bạn ít nhất có được một giao diện được biết - ví dụ IDispatch nếu bạn muốn các tính năng phản chiếu.

Đồng bằng duy nhất của bạn không bị gọi bằng ngôn ngữ khác khi đó sẽ là đăng ký và nhà máy của lớp học.

Answer 4

Với DLL bạn có thể nhận được nhiều khớp nối gần hơn, trong khi COM giới hạn tương tác rất chính xác. Đây là gốc rễ của cả những lợi thế và bất lợi!

Bạn nhận được nhiều quyền lực hơn và linh hoạt hơn (ví dụ: kế thừa từ các lớp được định nghĩa trong DLL, không khả thi trong COM), nhưng phụ thuộc sẽ mạnh hơn rất nhiều (cần phải xây dựng lại người dùng cho những thay đổi nhất định đối với DLL, v.v.).

Thường là đặc biệt là tất cả các tệp DLL và EXE phải sử dụng cùng một thư viện thời gian chạy và các tùy chọn (ví dụ: tất cả được liên kết động với phiên bản đa luồng không gỡ lỗi msvcrt* chẳng hạn - không thể xây dựng lại chỉ một phiên bản gỡ lỗi mà không bị lỗi rất có thể xảy ra!). Liên kết lỏng lẻo của COM do đó thường thích hợp hơn, trừ khi bạn thực sự cần các loại tương tác gần khớp trong một trường hợp cụ thể (ví dụ, một khung, chắc chắn yêu cầu mã người dùng kế thừa từ các lớp của nó, phải là một DLL).

Answer 5

Vì giao diện độc lập với bất kỳ DLL cụ thể nào, ở mức đơn giản nhất, một cách tiếp cận COM như ít nhất giúp bạn thay đổi dll phân phối giao diện dưới mui xe mà không phải biên dịch lại ứng dụng của bạn .

Sử dụng COM đầy đủ với các giao diện được xác định MIDL và dll proxy có nghĩa là bạn có thể sử dụng COM để quản lý an toàn luồng trong quá trình, xử lý liên kết trên cùng một PC hoặc thậm chí kết nối với đối tượng máy chủ COM trên máy tính từ xa.

Answer 6

Mọi người đều đề cập đến những thứ nằm trong cột cộng của COM. Tôi sẽ đề cập đến một vài điều thú vị.

• Khi bạn thực hiện hệ thống của bạn sử dụng COM, bạn cần đăng ký 'máy chủ' COM (có họ trong proc hoặc out-of-proc) tại thiết lập và unregister họ tại uninstall. Điều này có thể làm tăng sự phức tạp của hệ thống thiết lập của bạn một chút và có xu hướng yêu cầu khởi động lại trừ khi người dùng cẩn thận rớt xuống các quy trình đang chạy trước.

• COM chậm so với các cách tiêu chuẩn khác để thực hiện tương tự. Nhận xét này có lẽ sẽ tạo ra rất nhiều ghét và có thể một số downvotes, nhưng thực tế của vấn đề là tại một số điểm bạn sẽ cần phải marshall dữ liệu, và đó là tốn kém.

• Theo quy tắc của COM, khi giao diện đã được xuất bản, nó không bao giờ có thể thay đổi được. Điều đó trong chính nó không phải là một tiêu cực, và bạn thậm chí có thể lập luận rằng nó buộc bạn phải làm thiết kế kỹ lưỡng trước khi vận chuyển giao diện. Nhưng sự thật là không có thứ gì như vậy, và trong các giao diện mã sản xuất thay đổi. Bạn chắc chắn sẽ cần phải thêm phương thức hoặc thay đổi chữ ký của các phương thức hiện có. Để thực hiện điều này, bạn phải phá vỡ các quy tắc của COM - trong đó có các hiệu ứng xấu - hoặc tuân thủ các quy tắc của COM phức tạp hơn là chỉ thêm một tham số vào một hàm giống như bạn làm với một DLL thô.

Answer 7

Nếu bạn có thể tránh không sử dụng. Trong dự án cuối cùng của tôi, COM đã đưa ra nhiều hạn chế đối với các giao diện C++ đang được sử dụng. Chỉ cần tưởng tượng, rằng bạn không thể chỉ đơn giản là vượt qua một chuỗi std :: nhưng phải sử dụng một mảng các ký tự. Trong trường hợp đó bạn xây dựng chuỗi, sau đó sao chép nó vào một mảng có thể được xử lý bởi COM.

Bạn cũng chỉ có thể sử dụng tập hợp các loại cơ bản rất hạn chế, có phôi và quản lý bộ nhớ độc quyền. Bạn không thể sử dụng mới/xóa, nhưng phải sử dụng các hàm COM riêng.

Bạn cũng không thể chỉ đơn giản là ném một ngoại lệ, nhưng phải khởi tạo một số giao diện COM IErrorInfo, mà sẽ được rethrown ở đầu bên kia.

Vì vậy, nếu bạn không cần, đừng sử dụng. Nó chắc chắn sẽ vít thiết kế của bạn. Và nếu bạn cần nó, hãy thử để đánh giá khả năng interop khác: tăng :: interprocess, băng zeroc ...

Kính trọng,

Ovanes