Sembra che ci sia molta ostilità nei confronti di DCOM e sono curioso di capire perché. Per un'azienda che sta ancora scrivendo su SK32 Win32 usando C++, c'è qualche ragione per non utilizzare DCOM nello sviluppo attuale o futuro? Qualche versione futura di Windows non la supporta? È troppo fragile e non funziona spesso? È troppo complicato da implementare rispetto ad altre tecnologie? Qual è l'accordo?Cosa c'è di sbagliato in DCOM?
Bene, DCOM è una versione distribuita di COM e COM è molto complessa di per sé ed è molto facile fare qualcosa di sbagliato involontariamente (vedere this recent question e la risposta ad esso per gli esempi). Con DCOM hai solo altri modi per farti male.
Diverso da quello che funziona ed è ad esempio un buon modo per l'hosting di componenti COM in-proc in un processo separato.
In realtà trovo che la COM sia abbastanza comprensibile e piuttosto semplicistica se si comprendono i puntatori e i contatori di riferimento. – Charles
Credimi, le funzioni dei membri di IUnknown sono solo l'inizio. Poi vengono gli appartamenti, la concorrenza e altre cose che possono causare dolore orribile. – sharptooth
Quindi cosa consiglieresti per un SDK win32 locale solo per il servizio e l'app client che devono comunicare? Sì, DCOM è complicato, ma quale tecnologia non soddisfa questi requisiti? – Charles
Ho implementato un sistema di grandi dimensioni utilizzando DCOM alla fine degli anni '90. Sebbene funzionasse abbastanza bene, c'erano un paio di problemi. Per i principianti utilizza numeri di porta imprevedibili per la comunicazione. Non è scalabile, e stai molto meglio usando WCF che DCOM.
Sfortunatamente, siamo confinati nell'SDK Win32 - non è consentito .NET.Lo so, lo so, ma non faccio le regole – Charles
Ancora credo che potresti usare i servizi web - Sono abbastanza sicuro che ci siano pacchetti SOAP per C++. –
Se si tenta di creare un'applicazione server client e si desidera che la comunicazione superi i limiti della rete (ad esempio Internet), DCOM può essere problematico a causa dei firewall.
Avevo lavorato su un'applicazione server di successo che è stata distribuita utilizzando DCOM, permettiamo al sistema di gestire la maggior parte della complessità creando applicazioni server COM + ed esportando proxy applicazione. In questo caso ha funzionato molto bene finché tutte le nostre versioni sono state sincronizzate.
Ho dimenticato di menzionare il nostro client e il server sarebbe locale per la stessa macchina, entrambi scritti da noi e distribuiti insieme, quindi nessun problema di rete o di sincronizzazione. – Charles
Credo che lo slancio si è spostato a SOAP e altre tecnologie web service, perché è:
I Non ho mai usato DCOM da solo, quindi non posso davvero commentare la sua qualità generale o idoneità.
Suppongo che avrei dovuto dire che il mio utilizzo sarebbe per DCOM locale - sia client che server sulla stessa macchina. La conversione di tutto in ASCII e l'avvolgimento con più tag ASCII e l'analisi del risultato ASCII sono estremamente inefficienti. – Charles
Ah, ti sento. E sì, SOAP ha i suoi problemi. – CBFraser
Non mi piace COM/DCOM perché "Catastrophic failure" è il messaggio di errore più inutile nella cronologia dei messaggi di errore.
Questo sarebbe il messaggio di "benessere" per l'utente. In questo modo sanno che stanno facendo bene. – Jrud
ERROR_ALREADY_EXISTS per riassumere. – ActiveTrayPrntrTagDataStrDrvr
Se si desidera solo sviluppare in C++ e distribuire in rete controllata, potrebbe comunque essere una buona scelta.
I problemi di sicurezza tra i limiti del SO locale (qualsiasi cosa su un'altra macchina) non possono essere enfatizzati abbastanza. "Gestire" la sicurezza DCOM è assolutamente impossibile. (E buona fortuna cercando di rintracciare gli errori o interpretare i messaggi di errore.) –
tutto;) (Sto scherzando) –