Всем привет. Простой вопрос по guidelines.

Допустим я пишу сервис, который предполагается использовать асинхронно. Что-то вроде:

public interface IMyService
{
    IAsyncResult BeginGetSomething(...);
    ISomething EndGetSomething(IAsyncResult, ...);
}

Нужно ли мне делать в нем метод GetSomething для синхронного вызова, если такой usecase даже не предполагается?
Считается ли это обязательным, сталкивались ли вы с либами, где есть только BeginXxx/EndXxx методы?

Здравствуйте, MxMsk, Вы писали:

MM>Всем привет. Простой вопрос по guidelines.

MM>Допустим я пишу сервис, который предполагается использовать асинхронно. Что-то вроде:
сервис это типа web service/wcf? если да, то как его вызовут клиенты на java/c++ и прости-господи php?
Если только для .NET, то не проще ли вызвать синхронный метод асинхронно?
Да и как IAsyncResult будет серилизоваться не понятно.
MM>

public interface IMyService
MM>{
MM>    IAsyncResult BeginGetSomething(...);
MM>    ISomething EndGetSomething(IAsyncResult, ...);
MM>}

MM>Нужно ли мне делать в нем метод GetSomething для синхронного вызова, если такой usecase даже не предполагается?
MM>Считается ли это обязательным, сталкивались ли вы с либами, где есть только BeginXxx/EndXxx методы?

Здравствуйте, MxMsk, Вы писали:

MM>Всем привет. Простой вопрос по guidelines.
MM>Допустим я пишу сервис, который предполагается использовать асинхронно. Что-то вроде:

public interface IMyService
MM>{
MM>    IAsyncResult BeginGetSomething(...);
MM>    ISomething EndGetSomething(IAsyncResult, ...);
}

MM>Нужно ли мне делать в нем метод GetSomething для синхронного вызова, если такой usecase даже не предполагается?

Что значит "не предполагается" и почему? Что ошибочного будет в таком [клиентском] коде:

var result = service.BeginGetSomething(…);
var smth = service.EndGetSomething(result, …);

MM>Считается ли это обязательным, сталкивались ли вы с либами, где есть только BeginXxx/EndXxx методы?

Не виделось причин, по которым там не быть бы синхронным методам

Здравствуйте, MxMsk, Вы писали:

MM>Нужно ли мне делать в нем метод GetSomething для синхронного вызова, если такой usecase даже не предполагается?

Я бы не стал добавлять, в крайнем случае, написал бы extension-метод, для синхронных оберток.

Здравствуйте, cadet354, Вы писали:

C>Здравствуйте, MxMsk, Вы писали:

MM>>Всем привет. Простой вопрос по guidelines.

MM>>Допустим я пишу сервис, который предполагается использовать асинхронно. Что-то вроде:
C>сервис это типа web service/wcf? если да, то как его вызовут клиенты на java/c++ и прости-господи php?
C>Если только для .NET, то не проще ли вызвать синхронный метод асинхронно?
C>Да и как IAsyncResult будет серилизоваться не понятно.
Не, сервис — это просто некий сервисный класс. Ничего никуда не сериализуется и никаким java/c++ не зовется
Обычный асинхронный API делегатов .Net не подходит по тому, что IAsyncResult у меня расширений, с возможностью отмены.

Здравствуйте, _FRED_, Вы писали:

_FR>Что значит "не предполагается" и почему?
Скажем так. Идеология системы такова, что сервисы не должны работать в GUI потоке, а также должны поддерживать отмену вызова. Ну и чтобы навязать такое поведение, я и не стал делать "синхронную" сигнатуру. А теперь вот призадумался, не шибко ли жестко это.

_FR>Что ошибочного будет в таком [клиентском] коде:
_FR>

_FR>var result = service.BeginGetSomething(…);
_FR>var smth = service.EndGetSomething(result, …);
_FR>

В таком ничего ошибочного. Я спрашиваю, надо ли делать метод интерфейс таким:

public interface IMyService
{
    ISomething GetSomething();
    IAsyncResult BeginGetSomething(...);
    ISomething EndGetSomething(IAsyncResult, ...);
}

Здравствуйте, Lloyd, Вы писали:

L>Здравствуйте, MxMsk, Вы писали:
MM>>Нужно ли мне делать в нем метод GetSomething для синхронного вызова, если такой usecase даже не предполагается?
L>Я бы не стал добавлять, в крайнем случае, написал бы extension-метод, для синхронных оберток.
Тоже была такая мысль, но беспокоит, что в таком случае по-любому будет вызов в отдельном потоке. Если явно определить метод, то можно написать реализацию, использующую вызывающий поток.

Здравствуйте, MxMsk, Вы писали:

L>>Я бы не стал добавлять, в крайнем случае, написал бы extension-метод, для синхронных оберток.
MM>Тоже была такая мысль, но беспокоит, что в таком случае по-любому будет вызов в отдельном потоке. Если явно определить метод, то можно написать реализацию, использующую вызывающий поток.

Хм, об этом я не подумал.

Здравствуйте, MxMsk, Вы писали:

_FR>>Что значит "не предполагается" и почему?
MM>Скажем так. Идеология системы такова, что сервисы не должны работать в GUI потоке

То есть "сервисы"? Может бы, клиенты? А зачем сервису навязывать клиенту какой-то [асинхронный] определённый стиль работы Тем более, что синхронный режим, если захочет, клиент всё равно сделает.

MM>, а также должны поддерживать отмену вызова.

Это пускай и это не не имеет никакого отношения в [не]необходимости синхронного вызова.

MM>Ну и чтобы навязать такое поведение, я и не стал делать "синхронную" сигнатуру. А теперь вот призадумался, не шибко ли жестко это.

Дело нее в жёсткости, а в том, что даже без явного синхронно вызова клиент, если захочем, будет работать синхронно. Поэтому убирание в явном виде синхронного аналога во-первых, не имеет никакой ценности для производительности сервиса (разве что на один метод для каждой операции в интерфейсе меньше), во-вторых менее удобно для клиента в случае, если ему по каким-то причинам захочется синхронно вызвать метод и, в-третьих, рвёт привычный для .NET шаблон. ИМХО?, не одного стоящего бенефита против наличия синхронного метода.

_FR>>Что ошибочного будет в таком [клиентском] коде:

_FR>>var result = service.BeginGetSomething(…);
_FR>>var smth = service.EndGetSomething(result, …);

MM>В таком ничего ошибочного. Я спрашиваю, надо ли делать метод интерфейс таким:

public interface IMyService
MM>{
MM>    ISomething GetSomething();
MM>    IAsyncResult BeginGetSomething(...);
MM>    ISomething EndGetSomething(IAsyncResult, ...);
}

Так почему не сделать-то? Ведь мои две строчки — это и есть реализация ISomething GetSomething();

Вы же сказали, что, во-перых, синхронный вызов "не предполагается", но при этом, во-вторых, "В таком ничего ошибочного", хотя то, что я привёл как раз и есть же ничто иное как синхронный вызов Есть ли какой-то цимес в том, что бы искусственно ограничивать клианта в том, чего он и так может добиться?

Здравствуйте, MxMsk, Вы писали:

MM>Всем привет. Простой вопрос по guidelines.

MM>Допустим я пишу сервис, который предполагается использовать асинхронно. Что-то вроде:
MM>

public interface IMyService
MM>{
MM>    IAsyncResult BeginGetSomething(...);
MM>    ISomething EndGetSomething(IAsyncResult, ...);
MM>}

MM>Нужно ли мне делать в нем метод GetSomething для синхронного вызова, если такой usecase даже не предполагается?
MM>Считается ли это обязательным, сталкивались ли вы с либами, где есть только BeginXxx/EndXxx методы?

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

Здравствуйте, _FRED_, Вы писали:

_FR>Вы же сказали, что, во-перых, синхронный вызов "не предполагается", но при этом, во-вторых, "В таком ничего ошибочного", хотя то, что я привёл как раз и есть же ничто иное как синхронный вызов Есть ли какой-то цимес в том, что бы искусственно ограничивать клианта в том, чего он и так может добиться?
Примерно это и привело к созданию темы Я еще подумал, может оказаться так, что вызывающий код уже работает не в GUI-потоке, а тогда как раз и пригодится синхронный вариант. В-общем, делаем.

Здравствуйте, Lazin, Вы писали:

L>Думаю что не стоит добавлять синхронный метод, так как в каждом классе, реализующем этот интерфейс придется его реализовывать(конечно если классов не много, то это не проблема). Вместо этого, можно написать метод-расширение для интерфейса, который реализует синхронный метод используя асинхронные.
Этот вариант не совсем подходит. Уже написал почему

Автор: MxMsk
Дата: 22.10.10

.

L>>Здравствуйте, MxMsk, Вы писали:
MM>>>Нужно ли мне делать в нем метод GetSomething для синхронного вызова, если такой usecase даже не предполагается?
L>>Я бы не стал добавлять, в крайнем случае, написал бы extension-метод, для синхронных оберток.
MM>Тоже была такая мысль, но беспокоит, что в таком случае по-любому будет вызов в отдельном потоке. Если явно определить метод, то можно написать реализацию, использующую вызывающий поток.
то есть ваша асинхронная реализация используется внутри потоки для симуляции асинхронности? Тогда правильнее будет сделать базовый интерфейс синхронным, а расширять его асинхронной оберткой.

Здравствуйте, ononim, Вы писали:

O>то есть ваша асинхронная реализация используется внутри потоки для симуляции асинхронности? Тогда правильнее будет сделать базовый интерфейс синхронным, а расширять его асинхронной оберткой.
Не получится, т.к. нужно поддерживать отмену.