C # (wcf) architecture and directory structure (and instantiation)
Hi and thanks for any help.
I have a wcf service that I am trying to modulate correctly.
I am wondering if there is a better way or to implement the file and directory structure along with instanciatation, is there a better abstraction that may be missing?
Is this the best approach? especially if the performance and ability to handle thousands of concurrent requests?
I currently have the following structure:
-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 \ Customer \ 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
}
}
Note. In this example, I am not including the Customer object or the DataAccess libraries as I am only concerned about the service.
If you could let me know what you think if you know a better way or resource that might help.
Thanks, kindly. Stephen
source to share
I was using a web services factory software and loved its structure.
The structure in their example code was something like this:
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
source to share
This may be unconditional for a number of reasons, but I guess the breadth of the question will have a lot to do with it. Also, its a bit tricky to analyze projects with little context. There are also many questions here, which complicates the answer.
You first mentioned several classes that are not listed in your example code. I am assuming that Customer is referring to CustomerService as well as other mentioned classes and examples?
You asked if there is a better way to install. You may want to find design patterns such as the FlyWeight pattern and the Factory pattern to help you with this. I mention FlyWeight because you talked about performance.
The Design Patterns book will help you. Also, Martin Fowler's refactoring (albeit written in Java) will help a lot.
source to share
I don't know if this is the best (or even recommended) directory structure, but this is where I am currently settled.
.\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)
Based on this directory structure and what you have shown so far, the service class will be located in the MyProject.Services.Service folder under the MyProject.Services directory. The CustomerService class will be located in the MyProject.Services.Service.Support folder in the MyProject.Services directory.
I haven't worked with databases to understand the trade-offs between opening multiple concurrent connections or reusing the same connection over and over again. I am assuming the way you are doing this is the preferred solution.
And given that you defer your processing in the database every time you call the WCF service (by creating a new CustomerService object), you might find it helpful to make your WCF service a single. In general, WCF singlets are frowned upon for scalability reasons, as the assumption is that they share state between different service calls and therefore need to be synchronized. However, as shown, your WCF service does not maintain forward state. It simply accesses the database to create, update, delete, or retrieve the Client. As long as you access the database using an appropriate locking scheme, you can avoid the overhead of instantiating each call to your WCF service. To make your service standalone, use the following attribute in your service:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
public class Service : IService
{
}
source to share