O QUE É COM+ ?

KERPLUNK 11/06/2016 21:33:22
#463376 Resposta escolhida

Nossa, deu até uma nostalgia agora! COM+ é uma [Ô]evolução[Ô] do COM(Component Obect Model). Ele é base para várias tecnologias Microsoft como o ActiveX(não só o ADO, mas qualquer outro objeto ActiveX), é o COM quem faz o [Ô]meio campo[Ô] entre a linguagem em si e a parte binária. é bem complicado e tem muita coisa sobre isso. Mas é tecnologia que já está praticamente 100% substituída(e com vantagens) no .NET, apesar de ainda ser possível usá-lo mesmo no .NET. Por exemplo, é possível criar uma OCX ou DLL em .NET e [Ô]expô-la[Ô] ao COM+, isso significa que você pode fazer uma parte da sua aplicação em .NET e usar no VB6, por exemplo. Não recomendável, porque afinal, se está re-escrevendo, não tem porque usar o VB6, faça tudo em .NET logo.

KELLY 11/06/2016 22:10:18
#463380

Oi KERPLUNK, então o COM+ seria uma linguagem então?

KERPLUNK 11/06/2016 22:28:54
#463382

Não exatamente. Tente ver como várias camadas de uma operação mais complexa. Usando o ADO como exemplo:
- Abre a conexão com o banco e executa um comando SQL
- Ao executar o comando, o COM+ recebe a mensagem e a repassa ao MDAC
- O MDAC vai [Ô]interagir[Ô] com o COM, repassando o seu comando e os objetos necessários para o COM fazer a conexão com o banco. Geralmente usando o OLEDB como [Ô]ponte[Ô]
- Enfim tudo chega ao banco de dados que executa o comando e retorna um objeto.
- O COM recebe o que o banco respondeu e repassa ao MDAC que faz as conversões necessárias para que o ADO [Ô]entenda[Ô]
- Finalmente os dados chegam ao seu objeto ADO e você pode [Ô]usar[Ô].

Cada interação dessas é feita muito rápido, usando código altamente otimizado. Acho que é essa a ordem, talvez eu esteja enganado sobre a ordem de como executa tudo isso, mas em suma, é algo mais ou menos assim.

Sutilmente, pude notar um [Ô]hábito[Ô] que eu tinha que é mais ou menos o que você está fazendo. Você enxerga tudo como código. No final é mesmo tudo código, mas muito mais importante que o código em si, é entender os conceitos dele. Para entender OOP por exemplo, só código não basta, é preciso o entendimento de o que é e para que serve. Por isso que fico meio [Ô]irritado[Ô] quando falo sobre um conceito, que a maioria das vezes é a chave do entendimento e a pessoa pede [Ô]um exemplo[Ô]. Somente o código em si na maioria das vezes não serve para entender o conceito, por isso, entender conceitos é ainda mais importante que entender código. Veja o VB6 por exemplo, ele nada mais é que um compilador que [Ô]traduz[Ô] um dialeto [Ô]VB[Ô] para ActiveX. Por isso que qualquer projeto VB tem referências que já são [Ô]padrão[Ô] e não podem ser tiradas, como o MSCOMCTL, que é a DLL com os controles básicos do VB6. Mas quem enxerga apenas código, pensa que o VB6 é a IDE que aparece. Ela só é um auxiliar para compilar seu código para ActiveX que por si só é um monte de coisa para entender. E essa é a principal lição para entender como realmente programar. Enxergar a IDE como a [Ô]linguagem[Ô] ou qualquer outro componente como [Ô]linguagem[Ô] é um hábito que não vai ajudar a entender e por isso, vai te trazer grandes dificuldades quando quiser migrar para uma outra plataforma, como o .NET por exemplo. Pare de enxergar o [Ô]micro[Ô] e comece a entender o [Ô]macro[Ô] da coisa. Pare de focar no código e entenda para que ele serve e o que ele faz, isso vai fazer você entender qualquer [Ô]linguagem[Ô] sem nenhuma dificuldade. Decorar comandos, ou até mesmo sequência de comandos é péssimo hábito. Entenda o que é e para que serve cada coisa que será muito mais fácil.