C# (wcf) архитектура и структура каталогов (и экземпляр)

Question

Здравствуйте и спасибо за любую помощь.

У меня есть служба wcf, которую я пытаюсь правильно модулизовать.

Мне интересно узнать, есть ли лучший способ или реализовать структуру файлов и каталогов вместе с instanciatation, есть ли более подходящий способ абстракции, который может отсутствовать?

Это лучший подход? особенно если производительность и способность обрабатывать тысячи одновременных запросов?

В настоящее время у меня есть эта следующая структура:

-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 \ Клиент \ 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 
} 
 

}

Примечание : Я не включаю объект Customer или библиотеки DataAccess в этот пример, поскольку я только соглашаюсь об обслуживании.

Если вы можете сообщить мне, что вы думаете, если знаете лучший способ или ресурс, который может помочь.

Спасибо, пожалуйста. Steven

Answer 1

Я использовал фабрику программного обеспечения для веб-сервисов и полюбил ее структуру.

Структура в их примере кода было что-то вроде этого:

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

Это может быть unanswer по ряду причин, но я предполагаю, что широту вопроса будет иметь много общего с ним , Кроме того, его немного сложно анализировать проекты с небольшим контекстом. Здесь также много вопросов, что усложняет ответ.

Во-первых, вы упомянули несколько классов, которые не указаны в вашем примере кода. Я предполагаю, что Клиент ссылается на CustomerService, а также на другие упомянутые классы и примеры?

Вы спросили, существует ли лучший способ для обеспечения стабильности. Возможно, вам захочется найти шаблоны проектирования, такие как шаблон «FlyWeight» и шаблон «Factory», чтобы помочь вам в этом. Я упоминаю «FlyWeight», потому что вы говорили о производительности.

Книга шаблонов дизайна поможет вам. Кроме того, рефакторинг Мартина Фаулера (хотя и написанный на Java) поможет очень многое.

Answer 3

Я не знаю, что это Лучшая (или даже рекомендуемая) структура каталогов, но это то, на чем я сейчас обосновался.

.\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) 

На основе этой структуры каталогов и то, что вы показали до сих пор, класс обслуживания будет идти в папку MyProject.Services.Service в каталоге MyProject.Services. Класс CustomerService будет находиться в папке MyProject.Services.Service.Support в каталоге MyProject.Services.

Я не работал с базами данных, чтобы понять компромиссы между открытием нескольких одновременных подключений или повторным использованием одного и того же соединения снова и снова. Я предполагаю, что способ, которым вы это делаете, является предпочтительным решением.

И учитывая, что вы откладываете обработку в базе данных каждый раз, когда вы вызываете службу WCF (создавая новый объект CustomerService), вам может быть полезно сделать вашу службу WCF синглом. В общем, сингллеты WCF неодобрительно относятся к причинам масштабируемости, поскольку предположение состоит в том, что они разделяют состояние между различными вызовами службы и, следовательно, должны быть синхронизированы. Однако, как показано, ваша служба WCF не поддерживает прямое состояние. Он просто обращается к базе данных для создания, обновления, удаления или извлечения Клиента. Пока доступ к базе данных с использованием соответствующей схемы блокировки, вы можете избежать накладных расходов, связанных с инстанциями каждого вызова вашей службы WCF. Чтобы сделать ваш сервис одноточечным, используйте в своем сервисе следующий атрибут:

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