Home/ Questions/Q 6088031
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T11:56:17+00:00

I am currently in the process of developing a Web Service which should expose

  • 0

I am currently in the process of developing a Web Service which should expose a relatively large number of ways to interact with it.

For example, Clients may be able to interact with the Web Service in order to manage users or projects in a Database.

To that effect, I created the following classes:

  • Two Data Contracts: IUsersServiceContract and IProjectsServiceContract
  • Two Service Contracts Interfaces: IUsersServiceContract and IProjectsServiceContract

My question is the following:

Does it make sense to create two different Web Services, each with their own endpoint(s), instead of creating one big class that implements both Service Contracts Interfaces ?

Keep in mind that in reality I would have many more Service Contracts Interfaces that deal with different sorts of data.

From what I understand, using a partial class (split in multiple files) will allow me to create one big Web Service with only one Endpoint.

This has the disadvantage of dealing with one big class split in multiple files, i.e: its harder to maintain and more prone to errors if developers “don’t see the big picture”.

The other solution would be to have one Web Service per Service Contract Interface implemented.

In essence, if I have X Service Contracts Interfaces, I end up with X Web Services with X Endpoints.

Which solution would you choose and why ?

Thanks for your input !

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Personally I would not use partial classes for splitting a class; the sheer size motivating tgis split suggests that the class is too large and needs a refactoring. In my opinion partial classes main purpose is to add changes to auto generated code.

    Since service and endpoint configuration can be shared using named behaviours in web.config splitting the service should not be that cumbersome. But the split should be motivated by grouping of functionality.

    Without knowing the exact nature of you services it sounds like there could be a natural separation in two services; one for user related operations and one for project oriented operations.

    If the implemantation classes grows above what you think are reasonable sizes I would consider letting separate classes – or preferably interfaces – handle each methods inner logic and let the service implementation it self be a shallow facade that delegates its own method parameters to the correct logoc instance

    • 0