COM + 응용 프로그램을 만들면 마법사에서 라이브러리와 서버 응용 프로그램 중 하나를 선택할 수 있습니다.COM + 라이브러리 응용 프로그램의 목적은 무엇입니까?
서버 응용 프로그램은 별도의 프로세스로 활성화되며이를 사용하여 32 비트 in-proc COM 구성 요소로 64 비트 소비자를 저렴하게 상호 운용 할 수 있습니다.
호출자 프로세스에서 올바르게 활성화되는 라이브러리 응용 프로그램의 용도는 무엇입니까? 일반 old-proc COM 서버 대신 사용하는 이유는 무엇입니까?
여러 가지가 있습니다
실적 - 그것은 조금 빨리 당신이 메시지 자동화 (정렬 화 및 비 정렬 화)
분리를 통해 갈 필요가 없습니다 같다 - 많은 다른 응용 프로그램의 경우 라이브러리를 사용하고 있다면 각 복사본에 자체 복사본이 있습니다. MTA에 (다중 스레드 아파트) 사이의 차이점과 STA (단일 스레드 아파트 모델)를 처리 할 때이 점은 가장 중요하다
인 - PROC 서버 (
내가 몇 가지 더 정의를 편집하고 확인을 좀 더 참조를 싼 IPC/RPC를 할 수있는 좋은 방법입니다 (다른 모든 호출자에서 공유 정말 개체의 사용 주위에 모든 상태입니다.
개념에 대한 설명은 약 30 페이지에서 논의됩니다. "인과 관계는 여러 프로세스에서 임의의 수의 컨텍스트에 걸쳐있는 COM 메서드 호출의 분산 체인입니다. Tim Ewald의 훌륭한 저서 "Transactional COM +"의 2 장 페이지 ISBN : 0-201-61594-0
제 2 장 요약에서 직접 인용 한 내용은 다음과 같습니다. "개체는 개체 컨텍스트를 사용하여 컨텍스트와 상호 작용할 수 있습니다 이 두 개체는 COM + 런타임 서비스와 상호 작용할 수있는 인터페이스를 제공합니다.이 컨텍스트에 도달하는 코딩 스타일은 COM + 개발을 기존 COM 개발과 매우 다릅니다. "
마지막으로, 제 2 장 토론이 "왜 라이브러리 응용 프로그램을?", 그의 주장은 주로 COM 객체를 사용에서 같은 이유를 나타냅니다 (질문, 왜 그냥 평범한 구식 COM 다른?입니다) , 1. 각 응용 프로그램에는 자체 인스턴스가 있습니다. 2. 비 DLLhosthost.exe 프로세스로로드하십시오. 3. 오버 헤드가 훨씬 적습니다. 4. 공통 개체의 간단한 배포.
결론적으로 분산 형이 아니며 자연에서 트랜잭션이 아닌 경우 COM을 통한 COM + 사용에 실질적인 이점이 없을 수 있습니다. 그러나 COM + 응용 프로그램을 작성하여 LIBRARY 응용 프로그램으로 배포하면 COM 구성 요소와 조금 더 비슷하게 동작합니다.
희망이 있습니다.
주 목적은 COM+ application contexts의 혜택입니다.이 성공적으로 COM + 라이브러리 응용 프로그램 (물론 서버 응용 프로그램)에서 작동하는 동안 IObjectContext 또는 IObjectContextActivity에 대한
CoGetObjectContext은 순수에서 프로세스 구성 요소에서 E_NOTINTERFACE를 반환합니다.
보안 컨텍스트는 CoGetCallContext (ISecurityCallContext)을 통해서도 가능합니다.
성능이나 격리와 아무 관련이 없습니다.
사이트 메모로 COM + 라이브러리 응용 프로그램에서 사용할 수있는 기능을 확인하는 한 가지 방법은 dcomcnfg.exe를 실행하여 구성 요소 서비스, 컴퓨터, 내 컴퓨터, COM + 응용 프로그램으로 이동하고 새 라이브러리 응용 프로그램을 만들고 아직 사용 가능한 프로그램을 확인하는 것입니다. 서버 응용 프로그램과 반대 됨).
나는 전혀 얻지 못합니다. in-proc 서버가 사용될 때 각 클라이언트에 의해 별도로로드되고 마샬링은 사용되지 않습니다. – sharptooth
몇 가지 추가 단어를 추가했습니다. (COM + Server Apps와 COM + Library Apps의 차이가 아니라 "COM"과 "COM + Library Apps"의 차이점을 실제로 이해하고 있다고 생각하십니까?) –