Classe contra o componente vs controle

Artigo
02/25/2013

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

Observação
Este tópico são sobre formulários do windows e classes do ASP.NET.Esta discussão não se aplica a classes WPF para obter informações sobre como criar controles WPF, consulte Visão geral de criação de controle.

A lista a seguir fornece diretrizes amplas para implementadores.

Se a classe usa recursos externos mas não será usado em uma superfície de design, para implementar System.IDisposable, ou para derivar de uma classe que implementa direta ou indiretamente IDisposable.
Se sua classe será usada em uma superfície de design (como o designer de formulários ou de Web Forms), para implementar System.ComponentModel.IComponent, ou para derivar diretamente de uma classe que implementa ou indiretamente IComponent.Observe que IComponent estende IDisposable, então um tipo de IComponent é sempre um tipo de IDisposable .Um tipo de IComponent tem uma pequena sobrecarga de desempenho sobre um tipo de IDisposable que não é IComponent, mas isso é deslocado geralmente pela capacidade de localizar em tempo de design e em tempo de execução IComponent .(A situação é explicada posteriormente em este tópico.)
Se você desejar uma classe que é designable (usado em uma superfície de design) e empacotado por referência, você pode derivar de System.ComponentModel.Component.Component é a implementação base de um tipo de IComponent que é empacotada por referência.
Se você desejar uma classe que são projetáveis por valor, você pode derivar de System.ComponentModel.MarshalByValueComponent.MarshalByValueComponent é a implementação base de um tipo de IComponent que é empacotada por valor.
Se você quiser apresentar IComponent digite na sua hierarquia de modelo de objeto e não pode derivar de uma classe base como Component ou MarshalByValueComponent devido à herança única, implementa IComponent.
Se você desejar uma classe designable que fornece uma interface do usuário, a classe é um controle.Um controle deve derivar direta ou indiretamente de uma das classes base de controle: System.Windows.Forms.Control ou System.Web.UI.Control.

Observação

Se a classe não é nem designable contém recursos externos, você não precisa IComponent ou um tipo de IDisposable .

Observação
Se a classe não é nem designable contém recursos externos, você não precisa IComponent ou um tipo de IDisposable .

As definições do componente, o do controle, recipiente, e do site seguir.

Componente

Em .NET Framework, um componente é uma classe que implementa a interface de System.ComponentModel.IComponent 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.Um componente de .NET Framework satisfaz os requisitos gerais e além de isso fornece recursos como o controle sobre os recursos externos e suporte em tempo de design.

Controle sobre os recursos externos

A interface de IComponent estende a interface de IDisposable , que tem um método chamado Dispose no contrato.Em a implementação do método de Dispose , um componente deve liberar recursos externos explicitamente.Isso fornece uma maneira determinística de liberar recursos, em contraste com a limpeza nondeterministic padrão que acontece através de coleta de lixo.Os desenvolvedores devem se propagar Disposeem todo uma hierarquia de retenção para garantir que os filhos de um componente também liberem recursos.Além de isso, um componente derivado deve chamar o método de Dispose de sua classe base.

Observação
Mesmo quando você fornece o controle explícito sobre recursos com Dispose, você sempre deve fornecer a limpeza implícita entre finalizadora (destrutor) para impedir que os recursos escapem permanentemente se um usuário não chama Dispose no seu componente.

O exemplo a seguir mostra o padrão para implementar Dispose em um componente base e um componente derivado.

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 em .NET Framework é que são projetáveis, o que significa que uma classe que é um componente pode ser usada em um ambiente de (RAD) de desenvolvimento de aplicativos de rapid como Visual Studio.Um componente pode ser adicionado à caixa de ferramentas de Visual Studio, pode ser arrastado e solto em um formulário, e pode ser manipulado em uma superfície de design.Observe que o suporte básico em tempo de design para tipos de IComponent é compilado em .NET Framework; um desenvolvedor de componente não tem que fazer qualquer trabalho adicional para aproveitar a base em 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.

Hospedando um componente

Um componente pode ser localizado (hospedado) em um contêiner (definido mais adiante em este tópico).Quando um componente é localizado, interage com o recipiente através do site (definido posteriormente em este tópico) e tem a capacidade de consulta e obter serviços de seu recipiente através do site.Para garantir que os recursos são liberados quando um recipiente é rasgado para baixo, um contêiner deve implementar a interface de IDisposable .Em a implementação do método de Dispose , um contêiner deve liberar quaisquer recursos que comporta e chama o método de Dispose de cada um dos seus componentes contidos.

A retenção é lógica e não precisa ter uma representação visual.Um recipiente de camada intermediária que localize componentes de banco de dados é um exemplo de retenção não visuais.A retenção visual é considerada no windows forms designer e o Web Forms designer em Visual Studio.A superfície de design visual é um contêiner que hospeda o componente de formulário (na Web, componente da página).

Empacotamento um componente

Componentes podem ser remotos ou nonremotable.Componentes de Remotos são empacotados por valor ou por referência.Empacotamento envolve enviar objetos através de limites como Domínios de aplicativo (processos leve), processos, e mesmo computadores.Quando um objeto é empacotada por referência, um proxy é criado que faz chamadas remotas ao objeto.Quando um objeto é empacotada por valor, uma cópia serializada do objeto é enviada pelo limite relevante.

Componentes de Remotos que encapsulam os recursos do sistema, que são maiores, ou que existem como as únicas instâncias devem ser empacotado por referência.A classe base para componentes que é empacotada por referência é System.ComponentModel.Component.Essa classe base para implementar IComponent e deriva de MarshalByRefObject.Muitos componentes na biblioteca de classes de .NET Framework derivam de Component, incluindo System.Windows.Forms.Control (a classe base para controles de formulários do windows), System.Web.Services.WebService (a classe base para os serviços Web XML criados usando ASP.NET), e System.Timers.Timer (uma classe que gera eventos de retorno).

Componentes de Remotos que apenas o estado de propriedade deve ser empacotado por valor.A classe base para componentes que são empacotados pelo valor é System.ComponentModel.MarshalByValueComponent.Essa classe base para implementar IComponent e deriva de Object.Apenas alguns componentes na biblioteca de classes de .NET Framework derivam de MarshalByValueComponent.Todos esses componentes estão no namespace de System.Data (DataColumn, DataSet, DataTable, DataView, e DataViewManager).

Observação
As classes base para os objetos que são empacotados por valor e por referência Object MarshalByRefObjectsão e, respectivamente, mas as classes derivadas correspondentes são chamadas MarshalByValueComponent e Component.A lógica arquivo de esquema de nomeação é que o tipo mais comumente tem o nome mais simples.

Se um componente não será remoted, não derivam das implementações básicas para Component; em vez de isso, implemente IComponent diretamente.

Controle

Um controle é um componente que fornece (ou) permite recursos de (UI) da interface do usuário..NET Framework fornece duas classes base para controles: um para controles de formulários do lado do cliente windows e outro para controles de servidor de ASP.NET .Esses são System.Windows.Forms.Control e System.Web.UI.Control.Todos os controles na biblioteca de classes de .NET Framework derivam direta ou indiretamente de essas duas classes.System.Windows.Forms.Control deriva de Component e próprio fornece recursos de interface do usuário.System.Web.UI.Control implementa 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 oposto não é válido.

Contêiner e site

Se você estiver desenvolvendo componentes e controles para formulários do windows ou para páginas de Web Forms (páginas deASP.NET ), você não tem que implementar recipiente ou sites.Os designers para windows forms e formulários da Web são contëineres para formulários do windows e para controles de servidor de ASP.NET .Contêiners fornecem serviços para componentes e controles localizados dentro de eles.Em tempo de design, os controles são localizados no designer e obtêm serviços de designer.Para a abrangência, definições de um contêiner e um site são fornecidas abaixo.

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