Bonne conception de classe par exemple

J’essaie de trouver le meilleur moyen de concevoir une classe dont les propriétés sont conservées dans une firebase database. Prenons un exemple de base d’une Person . Pour créer une nouvelle personne et la placer dans la firebase database, je souhaite que la propriété DateOfBirth soit facultative (c’est-à-dire NULLable dans la firebase database).

Voici mon exemple de code:

 namespace BusinessLayer { class Person { public ssortingng FirstName { get; set; } public ssortingng LastName { get; set; } public DateTime DateOfBirth { get; set; } } } 

Je ne sais pas si les champs doivent être publics ou non. Devrais-je le faire comme ceci:

 class Program { static void Main(ssortingng[] args) { Person person1 = new Person("Kate","Middleton",null); } } 

ou comme ceci:

 class Program { static void Main(ssortingng[] args) { Person person1 = new Person(); person1.FirstName = "Kate"; person1.LastName = "Middleton"; } } 

Je me demande également comment je devrais traiter les propriétés facultatives de la classe. Une fois les champs renseignés, comment puis-je les sauvegarder dans la firebase database? J’ai une classe DatabaseComponenet pour enregistrer les informations. Comment puis-je traiter les options lors de l’enregistrement dans la firebase database?

Alors, est-ce que je ferais quelque chose comme ça:

 public int Save() { int personId; personId = DatabaseComponent.InsertPerson(FirstName, LastName, DateOfBirth); return personId; } 

Merci pour toute aide! Quelques URL utiles sur la bonne conception de classe seraient également appréciées.

Premièrement, je mettrais deux constructeurs publics distincts dans Person:

 namespace BusinessLayer { class Person { public Person(ssortingng firstName, ssortingng lastName): this(firstName, lastName, DateTime.Now) {} public Person(ssortingng firstName, ssortingng lastName, DateTime birthDate) { FirstName = firstName; LastName = lastName; DateOfBirth = birthDate; } public ssortingng FirstName { get; set; } public ssortingng LastName { get; set; } public DateTime DateOfBirth { get; set; } } } 

cela vous permet d’écrire les deux

 var p = new Person("Marilyin", "Manson"); var p2 = new Person("Alice", "Cooper", new DateTime(...)); 

et

 var p = new Person { FirstName="Marilyn", LastName="Manson" }; 

Je ne vois pas pourquoi vous devriez limiter à un seul formulaire.

En ce qui concerne DatabaseComponent, je suggérerais fortement d’écrire une méthode permettant d’enregistrer une personne au lieu de la signature que vous déclarez implicitement.

En effet, si un jour devait changer la définition d’une personne, vous devriez probablement changer le code à chaque fois que vous appelez la méthode Save() . En enregistrant simplement une personne, il vous suffit de modifier l’implémentation Save() .

Ne comptez-vous pas utiliser un ORM en passant?

Avec les initialiseurs de classe C # 3.0, je ne me donne plus la peine de fournir un constructeur qui me permet d’initialiser toutes les propriétés:

 var person1 = new Person { FirstName = "Kate"; LastName = "Middleton"; }; 

En ce qui concerne la méthode Save , je les mets généralement dans une classe de référentiel séparée:

 public int Save(Person person) { ... } 

et puis quand j’ai besoin de sauver une personne je fais:

 var person1 = new Person { FirstName = "Kate"; LastName = "Middleton"; }; var id = new PersonsRepository().Save(person1); 

Utilisez uniquement des constructeurs si certains champs sont obligatoires car il s’agit d’un moyen efficace de vous assurer que ces champs sont spécifiés.

Je ne sais pas si les champs doivent être publics ou non

Les champs désignent généralement des variables membres et celles-ci doivent toujours être privées. En ce qui concerne les propriétés je voudrais coller avec get / set pour les objects de firebase database.

Je me demande également comment je devrais traiter les propriétés facultatives de la classe. Une fois les champs renseignés, comment puis-je les sauvegarder dans la firebase database?

Enregistrer des éléments dans la firebase database est une toute autre histoire. Je n’essaierais pas d’inventer ma propre couche mais d’utiliser une couche existante. Il existe tout un ensemble d’ORM: s du plus simple au plus complet.

Jetez un coup d’œil à PetaPoco pour une alternative légère ou nHibernate pour une alternative plus complète.

Validation

Un moyen courant de s’assurer que les champs obligatoires sont correctement spécifiés et que des valeurs valides sont obtenues consiste à utiliser un cadre de validation. Il existe une version intégrée dans .net appelée DataAnnotations . Google et regarder quelques exemples.

Cela devrait être vérifié en utilisant des règles métier.

Je veux dire que si vous voulez un modèle commercial très réutilisable, les objects métier doivent être réutilisés ailleurs, dans différentes zones. Cela peut signifier que la même classe “A” pourrait convenir à l’état “X” dans certaines activités, mais dans une autre situation. , même classe “A”, ira bien dans l’état “Y”.

Il existe un bon modèle de conception vous permettant d’implémenter des validateurs métier appelé Spécification :

Cela peut être mis en œuvre de nombreuses façons, mais l’une des plus compactes consiste à créer des règles avec des expressions lambda.

Par exemple:

 someAInstance => someAInstance.Name != null && someAInstance.Age > 30 

Une autre méthode consiste à utiliser des bibliothèques de validation d’object existantes, telles que NHibernate Validator, qui peuvent être utilisées indépendamment sans NHibernate et vous permettent de définir des atsortingbuts dans les propriétés de classe telles que [NotNull] , [NotNullNotEmpty] et des règles plus complexes. Vous pouvez aussi utiliser des règles construites. -dans ceux-ci ou vous pouvez construire vos propres.

Apprenez-en plus en lisant cet article (vous y trouverez une liste de règles de validation prêtes à l’emploi) :

Notez que l’un des avantages les plus importants de NH Validator est qu’il peut être utilisé dans n’importe quelle couche, pas seulement dans la couche de données ou dans la couche métier. De plus, comme vous pouvez l’utiliser sans NHibernate, vous disposez d’une interface légère, simple et conviviale. – validateur d’objects en couches.