Quelqu'un a-t-il un bon article ou de bons conseils pour nommer les classes d'applications Web à plusieurs niveaux?

Question

Je suis habitué à la présentation donnée par LLBLGen lorsqu’elle génère des objets basés sur une structure de base de données, ce qui pourrait générer les fichiers de classe suivants pour un "utilisateur" donné. table dans la base de données:

/EntityClasses/UserEntity.vb
/CollectionClasses/UserCollection.vb

Ceci fournit certaines fonctionnalités de base pour l’accès aux données. Cependant, lorsque vous souhaitez implémenter une logique métier, comment la présentez-vous? Par exemple, étant donné une structure de table qui pourrait ressembler à ceci:

 USER
 userId
 firstName
 lastName
 username
 password
 lockedOut

Et si vous vouliez verrouiller un utilisateur? Quel code appelleriez-vous depuis la couche de présentation? Souhaitez-vous instancier la classe UserEntity et faites:

 User = new UserEntity(userId)
 User.lockedOut = true
 User.Save()

Ou pourriez-vous créer une nouvelle classe, telle que UserHelper (/BusinessLogic/UserHelper.cs), qui pourrait avoir une fonction LockOutUser. Cela changerait le code en:

 UH = new UserHelper()
 UH.LockOutUser(userId)

Ou pourriez-vous étendre la classe UserEntity de base et créer UserEntityExt qui ajoute la nouvelle fonctionnalité? Par conséquent, le code de la couche de présentation peut ressembler à:

 User = new UserEntityExt(userId)
 User.LockOutUser()

Ou ... feriez-vous autre chose?

Et quelles seraient les conventions de nommage de votre répertoire / espace de noms et de vos noms de fichier / classe?

Answer 1

Je pense que ce que vous recherchez est une couche de service qui serait placée au-dessus des objets de domaine. Vous avez essentiellement cela avec votre deuxième option bien que je puisse l'appeler UserService ou UserTasks. En encapsulant ce processus LockUser dans un seul endroit, il sera facile de changer plus tard quand plusieurs étapes ou d'autres objets de domaine pourraient être impliqués. Ce serait également le lieu idéal pour mettre en œuvre des transactions lorsque plusieurs appels à une base de données sont en cours.