 |
Effective COM: 50 Ways to Improve Your COM and MTS-based Applications
Be the First to Write a Review and tell the world about this title!People who purchase this book frequently purchase: Books on similar topics, in best-seller order:Books from the same publisher, in best-seller order:
In Effective COM, the authors, Don Box, Keith Brown, Tim Ewald, and Chris Sells, offer 50
concrete guidelines for creating COM based applications that are more efficient, robust, and
maintainable. Drawn from the authors' extensive practical experience working with and teaching COM,
these rules of thumb, pitfalls to avoid, and experience-based pointers will enable you to become a
more productive and successful COM programmer.
These guidelines appear under six major headings: the transition from C++ to COM; interfaces, the
fundamental element of COM development; implementation issues; the unique concept of apartments;
security; and transactions. Throughout this book, the issues unique to the MTS programming model are
addressed in detail. Developers will benefit from such insight and wisdom as:
- Define your interfaces before you define your classes (and do it in IDL)
- Design with distribution in mind
- Dual interfaces are a hack. Don't require people to implement them
- Don't access raw interface pointers across apartment boundaries
- Avoid creating threads from an in-process server
- Smart Interface Pointers add at least as much complexity as they remove
CoInitializeSecurity is your friend. Learn it, love it, call it
- Use fine-grained authentication
- Beware exposing object references from the middle of a transaction hierarchy
- Don't rely on JIT activation for scalability
and much more invaluable advice.
For each guideline, the authors present a succinct summary of the challenge at hand, extensive
discussion of their rationale for the advice, and many compilable code examples. Readers will gain a
deeper understanding of COM concepts, capabilities, and drawbacks, and the know-how to employ COM
effectively for high quality distributed application development.
Table of Contents
Preface ix
Shifting from C++ to COM 1
1. Define your interfaces before you define your classes (and do it in IDL). 1
2. Design with distribution in mind. 8
3. Objects should not have their own user interface. 17
4. Beware the COM singleton. 19
5. Don't allow C++ exceptions to cross method boundaries. 23
Interfaces 31
6. Interfaces are syntax and loose semantics. Both are immutable. 31
7. Avoid E_NOTIMPL. 36
8. Prefer typed data to opaque data. 38
9. Avoid connection points. 43
10. Don't provide more than one implementation of the same interface on a single object. 47
11. Typeless languages lose the benefits of COM. 52
12. Dual interfaces are a hack. Don't require people to implement them. 57
13. Choose the right array type (avoid open and varying arrays). 60
14. Avoid passing IUnknown as a statically typed object reference (use iid_is). 65
15. Avoid [in,out] parameters that contain pointers. 68
16. Be conscious of cyclic references (and the problems they cause). 72
17. Avoid wire_marshal,transmit_as, call_as, and cpp_quote. 76
Implementations 81
18. Code defensively. 81
19. Always initialize [out] parameters. 85
20. Don't use interface pointers that have not been AddRef'ed 90
21. Use static_cast when bridging between the C++ type system and the COM type system. 98
22. Smart interface pointers add at least as much complexity as they remove. 101
23. Don't hand-optimize reference counting. 107
24. Implement enumerators using lazy evaluation. 109
25. Use flyweights where appropriate. 112
26. Avoid using tearoffs across apartment boundaries. 115
27. Be especially careful with BSTRs. 118
28. COM aggregation and COM containment are for identity tricks, not code reuse. 120
Apartments 125
29. Don't access raw interface pointers across apartment boundaries. 125
30. When passing an interface pointer between one MTA thread and another, use AddRef. 129
31. User-interface threads and objects must run in single-threaded apartments (STAs). 131
32. Avoid creating threads from an in-process server. 133
33. Beware the Free-Threaded Marshaler (FTM). 136
34. Beware physical locks in the MTA. 142
35. STAs may need locks too. 146
36. Avoid extant marshals on in-process objects. 151
37. Use CoDisconnectObject to inform the stub when you go away prematurely. 154
Security 155
38. CoInitializeSecurity is your friend. Learn it, love it, call it. 155
39. Avoid As-Activator activation. 163
40. Avoid impersonation. 167
41. Use fine-grained authentication. 171
42. Use fine-grained access control. 178
Transactions 183
43. Keep transactions as short as possible. 183
44. Always use SafeRef when handing out pointers to your own object. 185
45. Don't share object references across activity boundaries. 188
46. Beware of exposing object references from the middle of a transaction hierarchy. 191
47. Beware of committing a transaction implicitly. 194
48. Use nontransactional objects where appropriate. 195
49. Move nontrivial initialization to IObjectControl::Activate. 198
50. Don't rely on JIT activation and ASAP deactivation to achieve scalability. 199
Epilogue 201
About the Authors 203
Index 205
|
|
