Classe ComplexObject

Classe de base pour tous les objets complexes.

Espace de noms: System.ServiceModel.DomainServices.Client
Assembly : System.ServiceModel.DomainServices.Client (dans system.servicemodel.domainservices.client.dll)

Utilisation

'Utilisation
Dim instance As ComplexObject

Syntaxe

'Déclaration
<DataContractAttribute> _
Public MustInherit Class ComplexObject
    Implements INotifyPropertyChanged, IEditableObject, INotifyDataErrorInfo

[DataContractAttribute] 
public abstract class ComplexObject : INotifyPropertyChanged, IEditableObject, INotifyDataErrorInfo

[DataContractAttribute] 
public ref class ComplexObject abstract : INotifyPropertyChanged, IEditableObject, INotifyDataErrorInfo

/** @attribute DataContractAttribute() */ 
public abstract class ComplexObject implements INotifyPropertyChanged, IEditableObject, 
    INotifyDataErrorInfo

DataContractAttribute 
public abstract class ComplexObject implements INotifyPropertyChanged, IEditableObject, 
    INotifyDataErrorInfo

Notes

Dans les Services RIA WCF, un type d'objet complexe est un type utilisateur personnalisé structurel qui peut être utilisé comme type de base. L'infrastructure fournit de nombreuse fonctionnalités de type entité, comme une génération de code client évoluée pour les types complexes et, pour l'essentiel, le comportement de l'infrastructure relativement aux types complexes est identique ou très similaire à celui des entités. Il existe toutefois des différences importantes entre un ComplexObject et un Entity. En particulier, les types complexes n'ont pas d'identité. Cela signifie qu'ils n'ont pas de membres marqués avec KeyAttribute, de sorte que les clients ne peuvent pas leur appliquer de mise en cache d'identité comme ils le font avec les entités. Les types complexes ne peuvent pas être partagés ou référencés à partir de plusieurs instances parentes et ne prennent pas en charge l'héritage.

Supposons que vous disposiez d'un type d'entité Customer avec un membre de type Address :

public class Address
{
    public string AddressLine1 { get;set }
    public string City { get;set }
    public string Region { get;set }
    public string PostalCode { get;set }
    public string Country { get;set }
}

public class Customer
{
    [Key]
    public string CustomerID { get;set; }
    public string CompanyName { get;set }
    public string ContactName { get;set }

    public Address HomeAddress { get;set; }
}

Les types clients générés correspondants à ces types seront les suivants :

public class Address : ComplexObject
{
    public string AddressLine1 { . . . }
    public string City { . . . }
    public string Region { . . . }
    public string PostalCode { . . . }
    public string Country { . . . }
}

public class Customer : Entity
{
    [Key]
    public string CustomerID { . . . }
    public string CompanyName { . . . }
    public string ContactName { . . . }

    public Address HomeAddress { . . . }
}

Notez que Address dérive de ComplexObject.

Génération de code

Les proxys clients générés pour les types complexes sont très similaires à ceux qui sont générés pour les entités. Y sont inclus les méthodes d'extensibilité partielle, les métadonnées de validation, etc. Les types complexes générés par le code dérivent de la classe de base ComplexObject. La logique d'accesseur Set de propriété générée pour les membres de types complexes et les membres de types complexes suivent les mêmes schémas de propriété que ceux utilisés pour les entités.

Métadonnées

Comme pour les entités, vous pouvez appliquer des métadonnées supplémentaires à vos types complexes sur le serveur via des classes associées pour que ces métadonnées circulent dans le système. De même, dans les cas où vous utilisez une couche d'accès aux données qui prend en charge les types complexes, les métadonnées de cette couche seront aussi appliquées (par exemple, en déduisant le StringLengthAttribute des membres d'après votre modèle Entity Framework). Les types complexes participent au pipeline de métadonnées de la même façon que les entités.

Validation

La validation des accesseurs Set de propriété s'effectue de la même façon pour les membres de types complexes que pour les membres d'entités. En outre, les erreurs de validation des membres de types complexes se propagent vers le haut de la hiérarchie de la relation contenant-contenu. La validation des heures d'envoi profondes s'effectue aux deux niveaux pour les membres de types complexes d'entités. Dans tous les cas, une erreur de validation imbriquée est signalée en tant qu'erreur sur chaque parent en remontant la hiérarchie. Par exemple, si le membre Customer.ContactInfo.HomeAddress.PostalCode n'est pas valide, cette erreur de validation apparaîtra dans les erreurs de validation des instances de Customer, ContactInfo et HomeAddress. Le ou les noms de membres figurant dans le ValidationResult utiliseront le chemin d'accès approprié à chaque niveau.

Suivi des modifications

Les membres de types complexes d'entités singletons (comme Customer.Address) participent pleinement au suivi des modifications et au reste du pipeline Accept/RejectChanges. À mesure qu'elles sont apportées aux membres de types complexes imbriqués, les modifications sont signalées en remontant la hiérarchie de la relation contenant-contenu, avec pour conséquence de modifier l'entité parente. Si des modifications sont rejetées au niveau de l'entité, toutes les modifications de types complexes sont annulées. D'un point de vue conceptuel, les membres de types complexes sont traités par le système comme le sont les propriétés des entités de types non complexes des niveaux supérieurs.

Les types complexes des membres de collections (par exemple, Customer.PhoneNumbers) ne font pas l'objet d'un suivi en profondeur. Ils sont validés en profondeur au moment de l'envoi, mais les erreurs de validation ne remontent pas jusqu'à l'entité, car les membres sont définis sur des instances de types complexes de la collection et l'entité parente ne suit pas les modifications, ajouts ou suppressions intervenant sur les instances de la collection. Pour modifier le contenu d'un membre de collection de type complexe, il convient d'assigner au membre une nouvelle instance de la collection.

Sessions de modification

Les membres de types complexes d'entités participent pleinement aux sessions de modification initiées via l'interface IEditableObject. Si un BeginEdit est réalisé sur une entité, l'instantané d'état de cette dernière comprend l'état de tous les types complexes imbriqués, de façon récursive. De même, si des CancelEdit/EndEdit sont réalisés, les modifications sont appliquées de façon récursive. ComplexObject lui-même implémente IEditableObject, de sorte que vous bénéficiez d'une prise en charge complète des types complexes non hébergés par des entités.

Sérialisation

Les membres de types complexes sont toujours sérialisés en profondeur sur la base des annotations DataContract/DataMember. Par opposition, la sérialisation des associations d'entités est régie par l'application d'IncludeAttribute.

Hiérarchie d'héritage

System.Object
  System.ServiceModel.DomainServices.Client.ComplexObject

Sécurité des threads

Tous les membres publics statiques (Partagés dans Visual Basic) de ce type sont thread-safe. Il n'est pas garanti que les membres d'instance soient thread-safe.

Plateformes

Plateformes de développement

Windows XP Édition familiale, Windows XP Professionnel, Windows Server 2003 , Windows Server 2008 et Windows 2000

Plateformes cibles

Change History

Voir aussi

Référence

Membres ComplexObject
Espace de noms System.ServiceModel.DomainServices.Client