Строго необходимо или выгодно разделять ServiceContract и реализацию службы WCF?

Question

Сегодня я начал играть с WCF. Одна вещь, которую я заметил, заключается в том, что по умолчанию Visual Studio определяет службу WCF в терминах ServiceContract, который является интерфейсом; и класс, фактически реализующий этот интерфейс. Однако в этой статье я обнаружил следующий фрагмент кода (что на самом деле делает код, не имеет значения):

[ServiceContract]
public partial class BookmarkService
{
    // in-memory resource collections
    Dictionary<string, User> users = new Dictionary<string, User>();
    Dictionary<string, Bookmark> bookmarks = new Dictionary<string, Bookmark>();
    [WebGet(UriTemplate = "users/{username}")]
    [OperationContract]
    User GetUserAccount(string username)
    {
        // ...

Итак, необходимо ли отделить интерфейс службы WCF от его реализации? Если в этом нет особой необходимости, предлагает ли это какие-либо преимущества по сравнению с тем, чтобы этого не делать?

Answer 1

Строго не нужно выделять сервисный контракт как интерфейс - как вы уже видели.

Но настоятельно рекомендуется сделать так:

• вы получите большегибкость
• вы получаете лучшую тестируемость

Сервисы WCF идеально подходят для использования интерфейсов для определения контракта , который сервис гарантирует, и отделения его от фактической реализации.

Кроме того, имея контракты в качестве интерфейсов, вы можете иметь один класс реализации службы, реализующий несколько интерфейсов служб - еще одна степень гибкости.