Classe vs. Componente vs. Controle

Artigo
08/01/2011

Este tópico define componente e controle; a discussão apresentada aqui deve ajudá-lo a decidir quando implementar uma classe que é um componente ou controle.

Observação
Este tópico é sobre Windows Forms e ASP.Classes de rede. Essa discussão não se aplica a classes do WPF para obter informações sobre autoria de controles do WPF, consulte Visão geral sobre criação de controles.

A lista a seguir fornece diretrizes amplas para implementadores.

Se sua classe usa recursos externos, mas não será usado em uma superfície de design, implementar System.IDisposable, ou derivar uma classe que direta ou indiretamente implementa IDisposable.
Se sua classe será usada em uma superfície de design (como o Windows Forms ou Web Forms designer), implementar System.ComponentModel.IComponent, ou derivar uma classe que direta ou indiretamente implementa IComponent. Observe que IComponent estende IDisposable, portanto, um IComponent tipo é sempre um IDisposable tipo. Um IComponent tipo tem um desempenho pequeno sobrecarga sobre um IDisposable tipo que não é um IComponent, mas isso geralmente é compensado pela capacidade de site um IComponent em tempo de design e em tempo de execução. (Localizando é explicado posteriormente neste tópico.)
Se desejar que uma classe que é projetáveis (usado em uma superfície de design) e é empacotada por referência, você pode derivar de System.ComponentModel.Component. Componenté a implementação base de um IComponent tipo que é empacotado por referência.
Se desejar que uma classe de projetáveis é empacotada por valor, você pode derivar de System.ComponentModel.MarshalByValueComponent. MarshalByValueComponenté a implementação base de um IComponent tipo que é empacotado por valor.
Se você quiser apresentar uma IComponent Digite na sua hierarquia de modelo de objeto e não pode derivar uma implementação básica, como Component ou MarshalByValueComponent devido a herança única, implemente IComponent.
Se desejar que uma classe projetáveis que fornece uma interface de usuário, sua classe é um controle. Um controle deve derivar direta ou indiretamente de uma das classes de controle base: System.Windows.Forms.Control ou System.Web.UI.Control.

Observação

Se sua classe for nenhuma projetáveis nem mantém os recursos externos, você não precisa de um IComponent ou um IDisposable tipo.

Observação
Se sua classe for nenhuma projetáveis nem mantém os recursos externos, você não precisa de um IComponent ou um IDisposable tipo.

Execute as definições de componente, o controle, o contêiner e o site.

Componente

No .NET Framework, um componente é uma classe que implementa o System.ComponentModel.IComponent interface ou que deriva direta ou indiretamente de uma classe que implementa IComponent. Em programação, o termo component é geralmente usado para um objeto que é reutilizável e pode interagir com outros objetos. A .NET Framework satisfaz os requisitos gerais de componente e Além disso, fornece recursos como controle sobre recursos externos e suporte de tempo de design.

Controle sobre recursos externos

O IComponent interface estende a IDisposable interface, que tem um método chamado Dispose no contrato. Em sua implementação da Dispose método, um componente deve liberar recursos externos explicitamente. Isso fornece uma maneira determinista para liberar recursos e, em contraste com a limpeza não determinísticas padrão que ocorre por meio da coleta de lixo. Os desenvolvedores devem propagar Disposeao longo de uma hierarquia de contenção para garantir que os filhos de um componente também liberar recursos. Além disso, um componente derivado deve chamar o Dispose o método de sua classe de base.

Observação
Mesmo quando você fornecer controle explícito sobre recursos por meio de Dispose, você deve sempre fornecer limpeza implícita, por meio do finalizador (destruidor) para impedir que os recursos de permanentemente vazar se um usuário falhar chamar Dispose no componente.

O exemplo a seguir mostra o padrão para a implementação de Dispose em um componente de base e em um componente derivada.

public class BaseComponent : IComponent {

   // IComponent extends IDisposable.
   public void Dispose() {
        Dispose(true);
     GC.SuppressFinalize(this); 
      }

   protected virtual void Dispose(bool disposing) {
      if (disposing) {
          // Free other state (managed objects).
      }
      // Free your own state (unmanaged objects).
   }

   // Simply call Dispose(false).
      ~BaseComponent(){
      Dispose (false);
   }
}
   
// Derived component.
public class DerivedComponent : BaseComponent {
   
   protected override void Dispose(bool disposing) {
      if (disposing) {
      // Free other state.
      }
      // You must invoke the Dispose method of the base class.
      base.Dispose(disposing);
      // Free your own state.
      ...
   }
   // No finalizer/destructor.
   // No Dispose() method.
}

' Design pattern for a base class.
Public Class BaseComponent
   Implements IComponent
   ' Implement IDisposable
   Public Overloads Sub Dispose() 
      Dispose(True)
      GC.SuppressFinalize(Me)
   End Sub

   Protected Overloads Overridable Sub Dispose(disposing As Boolean)
      If disposing Then
         ' Free other state (managed objects).
      End If
      ' Free your own state (unmanaged objects).
      ' Set large fields to null.
   End Sub

   Protected Overrides Sub Finalize()
      ' Simply call Dispose(False).
      Dispose (False)
   End Sub
End Class

' Design pattern for a derived component.
Public Class DerivedComponent
   Inherits BaseComponent

   Protected Overloads Overrides Sub Dispose(disposing As Boolean) 
      If disposing Then 
         ' Release managed resources.
      End If
      ' Release unmanaged resources.
      ' Set large fields to null.
      ' Call Dispose on your base class.
      Mybase.Dispose(disposing)
   End Sub
   ' The derived class does not have a Finalize method
   ' or a Dispose method with parameters because it inherits
   ' them from the base class.
End Class

Suporte em tempo de design

Um recurso importante de componentes do .NET Framework é que eles são projetáveis, o que significa que uma classe que é um componente pode ser usada em um ambiente de desenvolvimento (RAD) rápido de aplicativos, como Visual Studio. Um componente pode ser adicionado à caixa de ferramentas de Visual Studio, pode ser arrastado e solto sobre um formulário e pode ser manipulado em uma superfície de design. Observe que suporte base de tempo de design para IComponent tipos é incorporado a .NET Framework; um desenvolvedor de componentes não tem qualquer trabalho adicional para aproveitar a funcionalidade básica de tempo de design.

Para obter mais informações sobre suporte em tempo de design, consulte Atributos de tempo de design para componentes e Estendendo suporte em tempo de design.

Um componente de hospedagem.

Um componente pode ser localizado (hospedada) em um recipiente (definido mais adiante neste tópico). Quando um componente é localizado, ele interage com o recipiente através de seu site (definida mais adiante neste tópico) e tem a capacidade de consultar e obter serviços de seu recipiente através do site. Para garantir que os recursos são liberados quando um recipiente é subdividido, um contêiner deve implementar a IDisposable interface. Em sua implementação da Dispose método, um recipiente deve liberar todos os recursos que ele contém e chamar o Dispose o método de cada um dos seus componentes contidos.

Confinamento é lógico e não precisa ter uma representação visual. Um recipiente de camada intermediária que componentes de banco de dados de sites é um exemplo de confinamento não visuais. Detenção Visual é vista no designer do Windows Forms e Web Forms designer no Visual Studio. A superfície de design visual é um recipiente que hospeda o componente de formulário (formulários da Web, o componente de página).

Um componente de empacotamento.

Componentes podem ser remoto ou nonremotable. Componentes de remota são empacotados por referência ou por valor. Empacotamento envolve enviar objetos através de limites, como Domínios de Aplicativo (processos leves), processos e até mesmo máquinas. Quando um objeto é empacotado por referência, um proxy que faz chamadas remotas para o objeto é criado. Quando um objeto é empacotado por valor, uma cópia serializada do objeto é enviada através do limite relevante.

Remoto componentes que encapsulam os recursos do sistema, que são grandes ou que existe como instâncias isoladas devem ser empacotadas por referência. A classe base para componentes que são empacotados de referência é System.ComponentModel.Component. Essa classe base implementa IComponent e deriva de MarshalByRefObject. Muitos componentes na .NET Framework biblioteca de classes derivar de Component, incluindo System.Windows.Forms.Control (a classe base para controles Windows Forms), System.Web.Services.WebService (a classe base para XML Web services criados usando ASP.NET), e System.Timers.Timer (uma classe que gera eventos recorrentes).

Componentes de remota, basta mantém o estado devem ser empacotados por valor. A classe base para componentes que são empacotados de valor é System.ComponentModel.MarshalByValueComponent. Essa classe base implementa IComponent e deriva de Object. Somente alguns componentes do .NET Framework derivam de biblioteca de classe MarshalByValueComponent. Todos esses componentes estão na System.Data namespace (DataColumn, DataSet, DataTable, DataView, e DataViewManager).

Observação
A base de classes para objetos que são empacotados pelo valor e por referência são Object e MarshalByRefObject, respectivamente, mas as classes derivadas correspondentes são nomeadas MarshalByValueComponent e Component. A lógica por trás do esquema de nomeação é que o tipo mais comumente usado tem o nome mais simples.

Se um componente não será remoto, não derivar as implementações básicas para Component; em vez disso, implementar IComponent diretamente.

Controle

Um controle é um componente que fornece (ou ativa) os recursos de interface de usuário (UI). O .NET Framework fornece duas classes base para controles: um para controles de Windows Forms do lado do cliente e outro para ASP.NET controles de servidor. Esses são System.Windows.Forms.Control e System.Web.UI.Control. Todos os controles de .NET Framework biblioteca de classes derivam direta ou indiretamente essas duas classes. System.Windows.Forms.Controlderiva de Component e o próprio fornece recursos de interface do usuário. System.Web.UI.Controlimplementa IComponent e fornece a infra-estrutura em que é fácil adicionar funcionalidade de interface do usuário.

Observação
Cada controle é um componente, mas o inverso não é verdade.

Contêiner e Site

Se você estiver desenvolvendo componentes e controles de Windows Forms ou de páginas de Web Forms (ASP.NET páginas), não é necessário implementar contêineres ou sites. Os designers para o Windows Forms e Web Forms são recipientes para o Windows Forms e ASP.NET controles de servidor. Contêineres fornecem serviços para os componentes e controles situados dentro deles. Em tempo de design, os controles estão situados no designer e obter serviços do designer. Para completude, as definições de um recipiente e um site são fornecidas abaixo.

Container
Um recipiente é uma classe que implementa o System.ComponentModel.IContainer interface ou deriva de uma classe que implementa essa interface. Logicamente, um recipiente contém um ou mais componentes que são chamados de componentes de filhos do contêiner.
Site
Um site é uma classe que implementa o System.ComponentModel.ISite interface ou deriva de uma classe que implementa essa interface. Sites são fornecidos por um contêiner para gerenciar e comunicar-se com seus componentes filhos. Normalmente, um recipiente e um site são implementados como uma unidade.