Une BLL doit-elle être apatride?

Question

Je suis en train de jouer avec la construction d'une BLL pour mon application. D'après ce que j'ai vu/lu, il semble que le BLL devrait être apatride. Cela ne signifie-t-il pas que toutes les méthodes BLL pourraient être statiques? Ou aurais-je besoin au moins d'une instance de chaque classe BLL? Ce qui me semble étrange pour une raison quelconque, alors j'ai pensé que je ferais mieux de vérifier que je n'obtenais pas la mauvaise extrémité du bâton avant de plonger trop loin dans mon expérimentation. Je pense aussi que cela signifie que les objets BLL ne devraient jamais contenir de données, car les données représentent l'état - donc pour chaque opération BLL invoquée, toutes les données nécessaires doivent être requeried (ou extraites du cache), puis rejetées . Est-ce que ça te paraît correct?

Merci.

Answer 1

En théorie, oui, une BLL sans état peut signifier que toutes les méthodes peuvent être statiques. Cependant, certaines considérations peuvent vous pousser à utiliser des instances d'objets BLL plutôt que statiques.

1. Les méthodes statiques introduisent un couplage étroit entre les classes et vous empêchent d'utiliser, par ex. interfaces pour coupler les dépendances. L'utilisation d'interfaces améliore la testabilité de la BLL, car elle peut maintenant être raillée lors de l'écriture de tests unitaires pour la couche Service. Si vos méthodes BLL sont statiques, vous ne pourrez généralement pas le faire sans «solutions de contournement» (par exemple, vous aurez besoin de TypeMock ou Microsoft Fakes dans un environnement .Net). Sur une méthode BLL complexe (par exemple, une grande logique de transaction), vous pouvez refactoriser chacune de vos règles métier en plusieurs méthodes discrètes et, en sortie, accumuler toutes les violations de validation et de règle dans un seul agrégat. résultat contenant toutes les violations. Dans ce cas, il peut être fastidieux d'éviter que l'entité/les entités soient validées et d'accumuler les violations de règles, et de choisir à la place de les stocker de manière dynamique sur une instance de classe. Une classe de base ou générique pour votre instance BLL peut vous aider ici.