11 Responses to Использование общих типов в WCF методом “тюнинга” .svcmap-файла

  1. heeepi says:

    Круто! И конечно соглашусь с тем, что первый вариант с shared сборкой гораздо лучше остальных. Но иногда действительно просто нет вариантов и код сервиса недоступен. Вот только сомневаюсь что будет такой case, когда есть куча однотипных сервисов, которые используют один и тот же тип данных. Обычно структуру DataContract’ов проектируют под один сервис. Если появилась такая ситуация – я бы посмотрел в сторону архитектуры сервиса, скорей всего он просто неправильно спроектирован и стоит посмотреть в сторону унификации групп сервисов, которые работают с однотипными контрактами.
    И еще, третий вариант мне кажется будет достаточно сложно поддерживать потом.

    ЗЫ: Миш, с твоего разрешения я бы хотел эту запись перепостить на wcfnet.wordpress.com.

    • Вот только сомневаюсь что будет такой case, когда есть куча однотипных сервисов, которые используют один и тот же тип данных.

      Например, каждый сервис предназначен для работы со своей бизнес-сущностью, но у каждого есть метод Search, который имеет на входе структуру описывающую параметры поиска. Она может быть привязана к типам, а может быть весьма общей.
      Или, например, параметры пейджинга – они тоже будут одинаковыми. Да и вообще любые настройки/опции, которые не связаны с данными, а влияют на поведение сервиса, будут одними и теми же.
      Да, вариант с единым сервисом для всех сущностей может быть не применим.

      И еще, третий вариант мне кажется будет достаточно сложно поддерживать потом.

      Ну пока единственное, что кажется неудобным – лазить в svcmap при добавлении новых сервисов.
      Если нужно просто обновить референсы, то достаточно нажать Update… в контекстном меню.

      Миш, с твоего разрешения я бы хотел эту запись перепостить на wcfnet.wordpress.com.

      Не вопрос. Конечно.

      • heeepi says:

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

        >> Да, вариант с единым сервисом для всех сущностей может быть не применим.
        Почему?

        >> Ну пока единственное, что кажется неудобным – лазить в svcmap при добавлении новых сервисов.
        Как показывает мой опыт потом просто никто не может вспомнить такие хитрости и народ начинает лажать.

        • Вот как раз и смущает то, что для каждой бизнес-сущности делается отдельный сервис.

          А почему?
          Ведь у каждой сущности свои, никак не пересекающиеся операции. Например для сущности “Клиент” будут доступны операции “Выставления (генерации) счетов”, “Обновление баланса” и т.д. А для “Пользователь системы” будет “Смена пароля”, “Блокировка”, “Смена уровня привилегий”, и т.д.
          Общими у них будут, быть может CRUD операции, но только ради них объединять все в один сервис…

          Например, на моем текущем проекте ситуация примерно такая:

          1. над разными сервисами работают разные команды
          2. разные сервисы работают с разными базами
          3. сервисы имеют разные биндинги (часть специально затачивалась под rest-сервисы, чтобы работать с Android, остальные предоставляют только SOAP)
          4. у сервисов различаются политики аутентификации (и даже механизмы)
          5. сервисы релизятся в разное время

          При всем этом – это единый фреймворк для нескольких приложений. С общей бизнес-частью.
          Наверное, можно было предложить и другие варианты решений, но в текущем мне не видится сколько-нибудь серьезных недостатков (недостатки есть, но не на столько серьезные :)).

          Как показывает мой опыт потом просто никто не может вспомнить такие хитрости и народ начинает лажать

          Ну с этим (передачей знаний) нам приходится разбираться все равно. Так что одной хитростью больше, одной меньше🙂

          P.S. Я вот уже с ужасом думаю как передавать знания по Identity Foundation… Там вообще – неверный шаг в сторону и все накрылось, а информации в доступном виде все еще мало.

  2. heeepi says:

    Reblogged this on WCF Blog.

  3. heeepi says:

    Не могу почему то ответить на твой комментарий, поэтому в общем потоке сознания.

    1. Скорее над разными бизнес-сущностями. Если бы сервис был один, то он был бы менее подвержен изменениям.
    2. Это тоже потому что у тебя сервис и сущность неразрывно связаны.
    3. Если бы был один сервис, можно было бы его подтачить под rest и у тебя все api автоматом бы перевелось под rest. Было бы несколько сложнее, но это думаю гораздо дешевле. Твоя ситуация это скорей издержки поддержки реализованной инфраструктуры.
    4. Также есть ощущение что это издержки поддержки и допиливания.
    5. Опять же, скорее релизятся не сервисы, а бизнес-сущности.

    В общем, имхо хороший универсальный сервис в качестве слабоменяющегося инфраструктурного звена был бы гораздо лучше в этом случае.

    • У меня плохо укладывается, что такое

      универсальный сервис

      и почему он будет меняться слабо.

      Боюсь мы где-то друг-друга недопонимаем.
      Давай разберем на конкретном примере. Вот смотри, есть сервис для управления пользователями системы. Он позволяет выполнять простые CRUD операции и несколько специфичных, типа “Блокировка”, “Смена пароля”, “Смена привилегий на сущность XXX”. Логично предположить, что за каждой операцией стоит отдельный метод сервиса.
      Что будет если нам потребуется еще одна операция (пусть, например, это будет “Сброс павроля администратором”). Поменяется ли сервис с добавлением этой операции? В моем понимании, да.

  4. heeepi says:

    >> Логично предположить, что за каждой операцией стоит отдельный метод сервиса.
    В твоем примере все выглядит как то так:
    Сущность “пользователь” – Какой то репозиторий пользователей с кастомными операциями (возможно, это и есть сервис) – Типизированынй сервис поверх репозитория.

    Если логику репозитория и логику сервиса разделить, а ее разделить было бы очень неплохо, ибо ответственность у них разная, то получится что у тебя сервис будет носить чисто формальную функцию преобразования вызовов и никакой бизнес логики содержать не будет. А значит это сугубо инфраструктурный механизм, призванный передавать данные и делегировать вызовы. А значит его вполне можно унифицировать независимо от типа сущности. Как именно это сделать и насколько хорошо это покроет WCF уже вопрос другой. Надеюсь пояснил что такое универсальный сервис.

    >> и почему он будет меняться слабо.
    Потому что больше всего изменений – изменения бизнес-логики. Инфраструктура как правило меняется незначительно и если не мешать одно с другим, то изменений сервиса должно быть минимальное количество.

    >> Что будет если нам потребуется еще одна операция
    Операция добавится к сущности пользователя или в репозиторий. Сервис менять не надо, потому что он умеет нормально делегировать вызовы репозиторию и от конкретного типа сущности не зависит.

    • Надеюсь пояснил что такое универсальный сервис

      Я бы хотел увидеть пример интерфейса такого сервиса и сущности.
      Потому как идея нетипизированных сервисов мне пока не нраится.

      Какой в нем смысл?
      Мы оставляем только транспорт. При этом у нас остается задача писать код вызова методов сущностей, а значит еще и проверку параметров, сериализацию и десериализацию, свою клиентску часть, … – т.е. мы просто изобрели свой SOAP. А что мы выигрываем я не понимаю. Не нужно обновлять сервис? Ну да, зато надо обновлять все остальное.

      В общем, пока не очевидно. Было бы не плохо взглянуть на реальный пример где так сделано и сравнить с тем, что сделано у нас.

  5. Narsil says:

    а можно исходный код?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s