Сервис WCF должен обычно быть одиночным элементом или нет?
Нет никакого решения для этого в .net платформе.
http://www.eldos.com/sbb/sftpcompare.php основы список несвободных опций.
Ваша лучшая свободная ставка должна расширить SSH использование Granados. http://www.routrek.co.jp/en/product/varaterm/granados.html
3 ответа
good responses, but I think there is a problem in the original question. "Typical use" of a technology is a poorly formed question. No one has a "typical" scenario, and you should review the requirements of your particular problem before deciding on an implementation or approach. Your requirements should inform your solution.
For instance, Singletons [ie the Singleton pattern] is just another tool in our box, and like any tool, there are cases where it works, and others it does not. Specifically, if you need to centralize business logic [more applicable in a standalone application than a remote WCF service], or share memory or a resource, a Singleton works well. Of course, if you are sharing business logic, state is maintained in the call stack, and multi threading is moot. If sharing memory between consumer calls, then multi threading is an issue. As regards WCF, there are two modes [actually three, but the third is a special case of the first] of multi-threading behaviour you can specify,
// we are specifying that this service implementation is single-threaded
// and WCF should permit *at most* one call at a time. Any requests made
// simultaneously/concurrently are queued.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
public class SingleThreadedNonThreadSafeService : IService { ... }
and
// we are specifying that this service implementation is multi-threaded
// and [hopefully!] thread-safe. WCF should permit any number of threads,
// or any number of simultaneous concurrent calls.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
public class MultiThreadedThreadSafeService : IService { ... }
The Xml comments for ConcurrencyMode basically say the same thing as above.
If you DO NOT need to share business logic or memory between consumers, then DO NOT use a Singleton, the "model" DOES NOT fit the problem. It's like forcing a glass slipper on a step-sister's foot! And no one should ever have to see that.
Conversely, if no state is shared between calls, host an instance per-call\session.
Обычно НЕ . Синглтоны - это беспорядок, так как для того, чтобы они работали хорошо, вам нужно сделать их многопоточными, и это просто вызывает проблемы, если вы действительно действительно не знаете, что делаете.
Лучшая практика для WCF - это для использования создания экземпляров для каждого вызова - каждый запрос получает свою собственную копию класса обслуживания, никаких проблем с многопоточностью, хорошая производительность - хранить все, что необходимо для сохранения в базе данных - работает как шарм.
Единственный реальный сценарий, где Синглтон может иметь смысл, если вам нужно, чтобы все запросы службы использовались / обрабатывались физическим ресурсом, который доступен только в одном экземпляре - если ваша одноэлементная служба сериализует и, таким образом, защищает один ресурс, тогда имеет смысл использовать его.
Иначе - избавь себя от хлопот! : -)
Одноэлементные службы WCF вряд ли когда-либо должны использоваться. Синглтоны - враг масштабируемости! Они имеют смысл только в странных сценариях - ведение журнала в один файл, один коммуникационный порт или аппаратное устройство.
Как говорит Марк, лучший выбор для масштабируемости с WCF - это сервисы для каждого вызова (они предлагают лучший компромисс между производительностью и масштабируемостью. ). Услуги по вызову также очень хорошо работают с балансировкой нагрузки.