Comment regrouper des fonctions dans une classe ASP.NET?

Question

J'ai actuellement une classe VB.NET nommée "Clients". et sa taille n'a cessé de croître et j'ai maintenant une douzaine de fonctions. Existe-t-il un moyen de maintenir les fonctions dans la même classe? Dans la mesure où ils utilisent toujours des méthodes privées communes, mais regroupez-les par similarité.

Par exemple:

Class Customers
-GetData
---GetCustomerObject()
---GetCustomerFieldx()
-Lists
---GetSomeList()
---GetAnotherList()
-Maintenance
---AddCustomer()
---DeleteCustomer()
---UpdateCustomer()

MISE À JOUR: Je suppose que je ne savais pas très bien où je voulais que ce regroupement se produise. Je souhaite que les regroupements ressemblent presque à des espaces de noms / classes dans IntelliSense lorsque j'utilise ma classe Client. J'utilise actuellement les régions, mais elles ne m'aident qu'à voir le code, pas à utiliser la classe.

Answer 1

Je ne recommanderais pas aux régions de regrouper le contenu de vos fichiers de manière générale.

Si votre fichier atteint une taille telle que vous estimez devoir regrouper les éléments pour reprendre le contrôle, c’est un conseil que vous devriez essayer de refactoriser la classe en plusieurs classes, chacune étant responsable d’un sous-ensemble de ce que la classe originale a fait. que vous ne vous retrouviez pas avec le désordre immuable qui constitue l’objet Objet divin

Answer 2

Je ne vois pas de code vous indiquant comment mettre en œuvre les suggestions, je vais donc l'ajouter ici. Vous devez diviser le code en classes basées sur la fonction. Ajoutez ensuite le mot-clé namespace à chacune des classes que vous créez. Voici l'article MSDN avec plus de détails ( http://msdn.microsoft .com / fr-us / library / ms973231.aspx # assenamesp_topic3 ??). Voici le code psuedo. Ensuite, vous feriez référence au code en utilisant projectname.namespace.classname.method.

namespace Customers
-Class GetData 
---GetCustomerObject() 
---GetCustomerFieldx()
end namespace

namespace Customers 
-Class Lists 
---GetSomeList() 
---GetAnotherList() 
end namespace

namespace Customers 
-Class Maintenance 
---AddCustomer() 
---DeleteCustomer() 
---UpdateCustomer()
end namespace 

Answer 3

Utilisez des régions de code dans vos fichiers source. Cela vous donne des boutons développer / réduire afin que vous puissiez masquer des sections du fichier.

#Region "GetData"
    ... code ...
#End Region

#Region "Lists"
    ... code ...
#End Region

#Region "Maintenance"
    ... code ...
#End Region

Answer 4

Il me semble que la classe des clients en fait peut-être trop et doit être décomposée pour respecter le principe de responsabilité unique. L’idée est qu’une classe sache bien faire une chose et que l’obtention de données relève d’une responsabilité différente de celle qui consiste à exécuter une logique d’entreprise avec ces données. Je suis actuellement en train d'apprendre comment diviser mes classes monolithiques en classes plus petites et plus ciblées. Je ne peux donc pas vous donner de conseils avisés sur la manière de procéder. Cependant, il existe de nombreuses ressources sur le Web:

comme ça

Ayez un peu de google pour SOLID et oncle Bob (Robert C. Martin) pour une bonté supplémentaire.

Answer 5

La région est une solution que je recommande. Mais vous pouvez aussi utiliser des classes partielles.

Answer 6

Et rappelez-vous, lorsque vous divisez la classe en classes beaucoup plus petites, vous avez la possibilité de les placer dans un système d'espaces de noms d'une profondeur arbitraire. L'espace de noms Project.Customer.Data peut héberger les classes GetCustomerObject et GetCustomerField.

(Malgré tout, j'essaie de m'apprendre à appliquer SOLID à mon travail sur VB.NET. Est-ce le genre de chose que vous avez fini par mettre en œuvre?)