Utiliser get/set asp.net C# theres trop de propriétés

Question

Je suis habitué à créer une classe de propriétés où j'inclurais tous mes champs et je devrais écrire toutes les propriétés get/set puis avoir une autre classe Database où je ferais tout mes appels de base de données.

Properties Class 
    private int _intCard 
    public int IntCard 
    { 
     set { _intcard = value;} 
    } 
Constructor here 

En ce moment, cela ne se sent pas comme la bonne approche que j'ai plus de 120 propriétés que je vais traiter et semble vraiment beaucoup de temps pour avoir à écrire chacun de ces propriétés hors. J'aurai besoin d'ajouter une validation à certaines des propriétés est la raison pour laquelle je choisis de cette façon, je pourrais le valider dans la méthode set. Quelqu'un peut-il suggérer une autre façon que je pourrais examiner pour compléter le même résultat. Donc, en donnant les commentaires que je comprends mon design est imparfait c'est ce que je pensais venir dans cette question. J'ai une idée sur la façon de résoudre ce problème, mais je ne sais pas si c'est la bonne façon d'aborder cela. J'ai cherché des principes de conception d'objet et j'ai lu à ce sujet, mais j'aurai besoin de plus de temps pour comprendre ce qu'il m'apprend. Pour l'instant, je voudrais savoir si cette approche est la bonne façon

Je suis suivi des demandeurs nom, adresse, téléphone, numéro de fax, téléphone portable, altphone, altaddress, même pour le conjoint, puis les enfants, les références, les informations de l'entreprise ..... et ainsi de suite

Je ne vais pas mentir Je ne comprends pas encore les classes abstraites afin de mettre en œuvre si c'est l'approche que je devrais prendre, je vais prendre plus de temps pour apprendre cela, mais pour l'instant était espérant que ce serait approprié.

classes de biens seraient comme suit applicant.cs, applicantspouse.cs, applicantcontactinfo.cs, appreferences.cs ......

Est-ce le long des lignes de ce que je devrais faire?

Merci encore

Answer 1

En lisant les commentaires il semble que vous avez besoin d'au moins deux classes, son adresse quelque chose comme:

public class Person 
{ 
    Guid Id {get; set;} 
    string Name {get; set;} 
    // ad infinitum the truely unique things that relate to an Individual 

    Address BusinessAddress {get; set;} 
    Address HomeAddress {get; set;} 
    Person Spouse {get; set;} 
} 

public class Address 
{ 
    Guid Id {get; set;} 
    Line1 {get; set;} 
    // ad infinitum all the truly unique things that relate to an address 
} 

Ce qui précède est essentiellement pseudo-code et ne doit pas être lu comme "C'est exactement comment le faire", je n'ai pas par exemple déclaré si les propriétés sont privées/publiques/protégées ou en effet fourni un constructeur.

Mais cela montre comment vous pouvez utiliser d'autres classes comme propriétés et dans le cas de "Spouse" créer des objets assez riches et profonds Hiérarchies (Le conjoint peut contenir des adresses et potentiellement un autre conjoint - référence circulaire ahoy!) et utilisé pour rendre le code plus lisible et séparer la responsabilité du code pour encapsuler un «concept/entité/domaine» dans une seule unité dont le travail consiste à être «cette chose spécifique». Probablement utile d'examiner les concepts de POO comme l'encapsulation, l'héritage, etc. (essentiellement les quatre principes d'OO) ici pour avoir une idée de ce qu'un objet devrait représenter, ce lien a une brève introduction et devrait vous aider à décider comment classes et construire des objets plus utiles.

http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/

Answer 2

je ne peux pas empêcher de penser à votre modélisation objet n'est pas ici. Si vous avez une classe avec 120 propriétés, vous n'avez pas divisé cet objet en rôles/responsabilités séparés, etc. Je chercherais à augmenter (de façon dramatique) le nombre de classes que vous créez, et ainsi votre solution deviendra plus gérable.

Cela ne réduit pas le nombre de propriétés que vous devez gérer. Il peut être utile de considérer les objets immuables (avez-vous besoin de définir ces propriétés au-delà de la construction?), Et/ou l'utilisation du modèle Builder pour faciliter la construction.

Enfin, avez-vous besoin de exposer ces propriétés? Un élément clé de OO est disant aux objets de faire les choses pour vous, plutôt que d'obtenir leur contenu et de faire des choses pour eux. Si vous pouvez dire à un objet de faire quelque chose pour vous, vous n'avez probablement pas besoin d'exposer leurs champs (internes).

Answer 3

Dans c modernes # versions il y a un super SINTAX compact propriétés:

public class Properties { 
    public int IntCard { get; set; } 
} 

Ici C# gère la variable privée pour vous, de cette façon vous pouvez éviter beaucoup de frappes. Pour la validation, vous pouvez utiliser Annotations de données.Plus d'infos here

Hope it helps

Answer 4

S'il vous plaît noter que cela ne répond pas à vos problèmes de conception. Si votre base de données est sur sql-server, pour éviter de taper, vous pouvez utiliser une requête comme celle-ci (modifiez selon vos besoins) pour obtenir la liste de propriétés avec les types de données, puis copiez et collez les résultats. SQL SERVER DEMO

SELECT 'public ' + CASE DATA_TYPE WHEN 'smallint' THEN 'short' 
       WHEN 'bit' THEN 'bool' 
       WHEN 'smalldatetime' THEN 'System.DateTime' 
       WHEN 'datetime' THEN 'System.DateTime' 
       WHEN 'date' THEN 'System.DateTime' 
       WHEN 'uniqueidentifier' THEN 'System.Guid' 
       WHEN 'varchar' THEN 'string' 
       WHEN 'int' THEN 'int' 
       WHEN 'numeric' THEN 'decimal' 
       ELSE DATA_TYPE END 
      + CASE IS_NULLABLE WHEN 'NO' THEN '' ELSE '?' END 
      + ' ' + COLUMN_NAME 
      + ' { get; set; }' AS def 
FROM INFORMATION_SCHEMA.COLUMNS 
WHERE TABLE_NAME = 'YourTableName' 
ORDER BY IS_NULLABLE, ORDINAL_POSITION 

Answer 5

totalement d'accord avec @ brian-Agnew que si vous avez que beaucoup de propriétés dans 1 classe, alors vous avez probablement besoin de faire quelques refactoring que vous certainement n'avez pas assez séparation des préoccupations.

Cependant, même après un refactoring, vous aurez toujours les propriétés, il vaudrait donc la peine de regarder les attributs de validation de données. Par exemple, voici une marche bien de les utiliser avec MVC: http://www.asp.net/mvc/tutorials/older-versions/models-(data)/validation-with-the-data-annotation-validators-cs. Vous pouvez ensuite utiliser auto-implemented propriétés:

public int IntCard { get; set; } 

Answer 6

Tim,

En fonction de votre édition, vous regardez comme vous êtes sur la bonne voie. Vous devez briser les propriétés en postes spécifiques, par exemple:

public class Person 
    { 
     public string GivenName { get; set; } 
     public string Surname { get; set; } 
     public ContactInfo ContactInformation { get; set; } 
    } 

public class Applicant : Person 
    { 
     public Person Spouse { get; set; } 
     public List<Person> Children { get; set; } 
     public List<Reference> References { get; set; } 
    } 

public class ContactInfo 
    { 
     [Required] 
     [DataType(DataType.PhoneNumber)] 
     public string PhoneNumber { get; set; } 

     [DataType(DataType.EmailAddress)] 
     public string EmailAddress { get; set; } 

     public Address PrimaryAddress { get; set; } 
     public Address AlternativeAddress { get; set; } 
    } 

Ainsi, les points clés pour vous voici que

1. la classe sont décomposées en morceaux maniables, réutilisables
2. données Annotations (Obligatoire & DataType dans la classe ContactInfo) sont utilisées pour valider les propriétés
3. Les propriétés n'ont plus besoin de variables privées explicites

P.S. Un peu plus d'informations sur les annotations de données: http://msdn.microsoft.com/en-us/library/dd901590(v=vs.95).aspx