C# objets multiples vs classes multiples

Question

J'ai une classe dans la couche d'accès aux données, disons BaseDAL qui a des méthodes standard Insert, Update, Delete. Est-il bon d'utiliser la même classe de ma couche de logique métier pour toutes les entités de mon application ou de créer plusieurs classes DAL pour toutes les entités et de les utiliser pour l'accès aux données? En d'autres termes, quoi de mieux? Plusieurs instances de la même classe desservant de nombreux clients ou des instances distinctes de classes distinctes desservant leurs entités respectives?

Answer 1

Cela dépend de la fréquence à laquelle vous devez changer d'entité, de la flexibilité dont vous avez besoin et de la vitesse à laquelle vous devez écrire le code. Selon les bonnes pratiques, vous devez créer une classe d'entité distincte pour chaque couche (couche DAL, BL, couche Présentation). Et il en résultera une architecture plus flexible. Mais l'inconvénient d'une telle solution est que vous devez écrire beaucoup de méthodes de conversion, la performance tombe souvent un peu, et le plus important - si vous effectuez un changement vertical (qui affecte toutes les couches) - vous devez changer beaucoup de code. Donc, si votre application est à usage unique et que vous savez qu'elle ne durera pas plus de quelques semaines/mois, il peut être justifié de ne pas créer autant de flexibilité en faveur de la création de l'application plus rapidement. Mais je le souligne une fois de plus - seulement pour les petites applications de courte durée. J'utilise souvent une interface de base commune avec toutes les propriétés publiques pour ces classes d'entité de toutes les couches (j'ai habituellement 3 classes d'entités: pour DAL, BL, PL séparément) et j'écris pour elles une classe de convertisseur unique. Il a toujours assez de flexibilité en cas de besoin, mais permet d'écrire moins de code. Désolé, j'ai mal compris la question au début. En ce qui concerne les classes de référentiel d'accès aux données, il est bien sûr préférable de diviser la fonctionnalité en parties (probablement en fonction du type d'entité). Sinon, vous obtiendrez bientôt un fichier de cent mille lignes.

Et il y a aussi un principe de conception "Principe de responsabilité unique". Selon lui, il est également préférable de diviser les fonctionnalités. Bien qu'il puisse être considéré que toutes les méthodes d'accès aux données ont une responsabilité unique au niveau le plus élevé, elles font des actions très différentes et travaillent avec des entités différentes.

Answer 2

Quelque chose comme ceci:

public interface IPerson 
{ 
    string Name{get;set;} 
    string LastName{get;set;} 
    //do not add fields which client doesn't need 
} 

public class PersonServerSide : IPerson 
{ 
    //implement IPerson 
    public string SSN{get;set;} //client doesn't need this for example 
} 

public class PersonClientSide : IPerson 
{ 
    //implement IPerson 
}