Блог

Сегодня я начал играть с 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 от ее реализации? Если это не является строго необходимым для этого, дает ли это какие-либо преимущества по сравнению с отказом от этого?

Нет строгой необходимости отделять контракт на обслуживание как интерфейс — как вы видели.

Но это крайне желательно сделать:

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

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

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