C# (wcf) architecture structure de fichiers et de répertoires (et instanciation)

Question

Bonjour et merci pour toute assistance.

J'ai un service wcf que j'essaie de modulariser correctement. Je veux savoir s'il y a une meilleure façon d'implémenter la structure de fichiers et de répertoires avec l'instanciation, y a-t-il un moyen d'abstraction plus approprié que je puisse manquer?

Est-ce la meilleure approche? surtout si la performance et la capacité à gérer des milliers de demandes simultanées?

Actuellement, je cette structure suivante:

-Root \ Service.cs

 
public class Service : IService 
{ 
    public void CreateCustomer(Customer customer) 
    { 
     CustomerService customerService = new CustomerService(); 
     customerService.Create(customer); 
    }
 

public void UpdateCustomer(Customer customer) 
{ 
    CustomerService customerService = new CustomerService(); 
    customerService.Update(customer); 
} 
 

}

-Root \ Client \ CustomerService.cs

 
pulbic class CustomerService 
{ 
    public void Create(Customer customer) 
    { 
     //DO SOMETHING 
    }
 

public void Update(Customer customer) 
{ 
    //DO SOMETHING 
} 

public void Delete(int customerId) 
{ 
    //DO SOMETHING 
} 

public Customer Retrieve(int customerId) 
{ 
    //DO SOMETHING 
} 
 

}

Remarque : Je n'inclut pas les bibliothèques Customer Object ou DataAccess dans cet exemple car je suis uniquement conc intéressé par le service.

Si vous pouviez soit me dire ce que vous en pensez, si vous connaissez un meilleur moyen, ou une ressource qui pourrait aider.

Merci Cordialement. Steven

Answer 1

J'ai utilisé une usine de logiciels de services Web et j'ai aimé sa structure.

La structure dans leur code d'échantillon était quelque chose comme ceci:

BYA.Mfg.SCM.Svc.WCF 
    Source 
    Business Logic 
     BYA.Mfg.SCM.Svc.WCF.BusinessEntities 
     BYA.Mfg.SCM.Svc.WCF.BusinessLogic 
    Resource Access 
     BYA.Mfg.SCM.Svc.WCF.DataAccess 
    Service Interface 
     BYA.Mfg.SCM.Svc.WCF.DataContracts 
     BYA.Mfg.SCM.Svc.WCF.FaultContracts 
     BYA.Mfg.SCM.Svc.WCF.MessageContracts 
     BYA.Mfg.SCM.Svc.WCF.ServiceContracts 
     BYA.Mfg.SCM.Svc.WCF.ServiceImplementation 
    Tests 

Answer 2

Cela peut être unanswer pour un certain nombre de raisons, mais je suppose que la largeur de la question aurait beaucoup à faire avec elle . Aussi, c'est un peu difficile d'analyser des conceptions avec peu de contexte. Il y a aussi beaucoup de questions ici, compliquant la réponse. D'abord, vous avez mentionné plusieurs classes qui ne figurent pas dans votre exemple de code. Je suppose que le client se réfère à CustomerService et de même pour les autres classes et exemples mentionnés?

Vous avez demandé s'il existait une meilleure méthode d'installation. Vous pouvez rechercher des motifs de conception comme le motif "FlyWeight" et le motif "Factory" pour vous aider dans cette tâche. Je mentionne "FlyWeight" parce que vous avez parlé de performance.

Le livre Design Patterns vous aidera. En outre, Refactoring par Martin Fowler (bien que écrit en Java) aidera beaucoup.

Answer 3

Je ne sais pas que c'est le meilleur meilleur ( (ou même recommandé) structure de répertoire, mais c'est ce que je me suis arrêté pour l'instant.

.\MyProject 
|----\bin 
|----\MyProject         (main application) 
|----\MyProject.Core       (shared libraries) 
|----\MyProject.Server       (WCF-hosting Windows service) 
|----\MyProject.Services      (the WCF services) 
|---------\MyProject.Services.Service1   (WCF Service1) 
|---------\MyProject.Services.Service1.Support (WCF Service1-specific libraries) 
|---------\MyProject.Services.Service2   (WCF Service2) 
|---------\MyProject.Services.Service2.Support (WCF Service2-specific libraries) 

Sur la base de cette structure de répertoires et ce que vous avez montré jusqu'à présent, la classe de service irait dans un dossier MyProject.Services.Service sous le répertoire MyProject.Services. La classe CustomerService irait dans un dossier MyProject.Services.Service.Support sous le répertoire MyProject.Services.

Je n'ai pas suffisamment travaillé avec les bases de données pour comprendre les compromis entre l'ouverture de plusieurs connexions simultanées ou simplement la réutilisation répétée de la même connexion. Ma conjecture est que la façon dont vous le faites est la solution préférée. Etant donné que vous reportez votre traitement à la base de données chaque fois que votre service WCF est appelé (en créant un nouvel objet CustomerService), vous pourriez bénéficier de faire de votre service WCF un singleton. En général, les singletons WCF sont désapprouvés pour des raisons d'évolutivité car l'hypothèse est qu'ils partagent l'état entre divers appels de service et doivent donc être synchronisés. Cependant, comme indiqué, votre service WCF ne gère aucun état directement. Il accède simplement à la base de données pour créer, mettre à jour, supprimer ou récupérer le client. Tant que l'accès à la base de données en utilisant le schéma de verrouillage approprié, vous pouvez éviter le surcoût associé aux instanciations par appel de votre service WCF. Pour que votre service devienne un singleton, utilisez l'attribut suivant sur votre service:

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)] 
public class Service : IService 
{ 
}