Member Avatar for Dendei

Hey im just wondering if or how i can split up my services

IService

namespace Phpwcfconsole
{
    // NOTE: You can use the "Rename" command on the "Refactor" menu to change the interface 
    name "IService1" in both code and config file together.
    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        string KundNyKund(Variables.Kunder Kund);

        [OperationContract]
        Variables.StringArrays KundVisaKund(); 

    }

Service1

namespace Phpwcfconsole
{
    // NOTE: You can use the "Rename" command on the "Refactor" menu to change the class name "Service1" in both code and config file together.
    public class Service1 : IService
    {
        public string KundNyKund(Variables.Kunder Kund)
        {
            //dostuff
        }
        public Variables.StringArrays KundVisaKund() 
        {
            //dostuff
        }
    }

so can i splitt Service1 into two files .cs
so for example i can have cutsomers and orders logic seperate?

  • 2 Contributors
  • 2 Replies
  • 207 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Dendei

Dani AI

Generated

As pointed out, splitting a WCF service implementation across multiple .cs files is perfectly fine — use C# partial classes to break the Service class into logical files (customers, orders, etc.). Partial parts are merged at compile time, must use the same assembly/namespace and accessibility, and are purely a source-organization feature (they don’t change the WCF contract or hosting behavior). (learn.microsoft.com)

If the intent is more than file-organization — for example different surface APIs, different bindings/security, or independent versioning — prefer separate service contracts (ICustomerService, IOrderService). A single class may implement multiple service contracts, and each contract can be exposed on its own endpoint (different addresses or bindings) so that clients can bind to the contract/version they need. That pattern helps with versioning and with applying different policies per contract. (learn.microsoft.com)

Small pattern to combine both ideas: keep the WCF class as a thin façade, split its implementation files via partial classes, and delegate business rules to dedicated manager classes. Example (illustrative only):

// BusinessService.Customers.cs
public partial class BusinessService : ICustomerService
{
    public void AddCustomer(CustomerDto dto) => _customerManager.Add(dto);
}

// BusinessService.Orders.cs
public partial class BusinessService : IOrderService
{
    public void CreateOrder(OrderDto dto) => _orderManager.Create(dto);
}

This keeps the service-layer surface small while the real logic lives in testable business-layer classes. (guidanceshare.com)

Quick tips/troubleshooting: keep OperationContract/DataContract attributes on the contract and DTO types (not split across partial files), ensure both partial files compile into the same assembly, avoid duplicate method signatures, and if exposing multiple contracts check endpoint configuration (addresses/bindings) so each contract is reachable. For endpoint/address guidance see the WCF endpoint docs. (learn.microsoft.com)

As noted in the thread, ’s partial-class route is the fastest fix for file splitting and confirmed it works; for longer-term structure, consider separate contracts + a thin WCF façade over a business layer.

Recommended Answers

All 2 Replies

Member Avatar for Dendei

sorry for no reply, yes i looked it up and got it to work thank you for the tip :)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.