Pamięć podręczna ChannelFactory WCF

Właśnie to przeczytałemświetny artykuł na buforowanie WCF ChannelFactory przez Wenlong Dong.

Moje pytanie brzmi: w jaki sposób można udowodnić, że ChannelFactory jest w rzeczywistości buforowany między rozmowami? Przestrzegałem zasad dotyczących konstruktorów bazy klientów. Używamy następującego przeciążonego konstruktora w naszym obiekcie, który dziedziczy z ClientBase:

ClientBase (string endpointConfigurationName, EndpointAddress remoteAddress);

W artykule wspomnianym powyżej stwierdza się, że:

Dla tych konstruktorów wszystkie argumenty (w tym argumenty domyślne) znajdują się na następującej liście:

· InstanceContext callbackInstance

· String endpointConfigurationName

· EndpointAddress remoteAddress

Tak długo, jak te trzy argumenty są takie same, gdy tworzona jest baza ClientBase, możemy bezpiecznie założyć, że można użyć tego samego ChannelFactory. Na szczęście typy String i EndpointAddress są niezmienne, tzn. Możemy dokonać prostego porównania, aby określić, czy dwa argumenty są takie same. Dla InstanceContext możemy użyć porównania referencji do obiektu. Typ EndpointTrait jest zatem używany jako klucz pamięci podręcznej MRU.

Aby przetestować teorię pamięci podręcznej ChannelFactory, sprawdzamy kod Hashcode w konstruktorze ClientBase, np. var testHash = RuntimeHelpers.GetHashCode (base.ChannelFactory);

Wartość mieszania jest różna w zależności od wywołania, co sprawia, że ​​uważamy, że ChannelFactory nie jest w rzeczywistości buforowany.

jakieś pomysły?

pozdrowienia

Myles

questionAnswers(2)

yourAnswerToTheQuestion