I read a post one of my colleagues, Yuval Mazor, had written -
ReactiveQueue Example: Increasing Throughput for Stateless WCF services
After reading the post I decided I have to comment on this.
I must say, I enjoyed the blog post and it does show what RxContrib can do for you, a really good job.
I understand the example there is just for the sake of showing RxContrib capabilities but I feel like I have to say a couple of words about it :)
In general, you should always design your services properly to meet its purpose and requirements.
I don’t want to get into a deeper conversation regarding SOA principles and where developers usually get it wrong, but this is a good example for that :)
Exposing a functionality in a service is the most basic “SOA” manner does get you to say “Yippy, I’m doing SOA”, but it can certainly be that you’re doing it the wrong way.
Looking at the service example in Yuval’s post – a common stateless logging service which should be available to large amount of client calls.
- The service in that example is configured as a singleton and with single concurrency mode – Why?
- If the solution to improve its throughput is to move all calls to a concurrent queue manipulation technique – Why not handle calls concurrently in the service level?
- If the service is stateless and no synchronization or ordering is important – Why not make it PerCall?
- Low on resources and doing IO work – Consider implementing the service in asynchronous pattern.
- Consider making the operation One-way and choose appropriate bindings
Actually, if the service had been designed better, I don’t think you would benefit all that much from using RxContrib in this case. on the contrary, it may even affect it to the worse, though I have to say I didn’t check it.
In conclusion, you should always examine your services in a systematic view and design it properly to meet your requirements. Otherwise, it is just plain bad SOA.
I thought this might be useful in some cases so I decided to write about it.
This is how you can get the machine’s FQDN in C#:
Dns.GetHostEntry("localhost").HostName
Silverlight includes a Full Screen capability where you can view your application in full screen.
This can be done by setting the “IsFullScreen” property to true -
Application.Current.Host.Content.IsFullScreen = true;
It basically turns your Silverlight application into a full screen view.
You can set it back to false in order to exit the full screen mode. In addition, the user can press the escape key and exit the full screen at any time.
Recently I was involved in a project where the following requirement was presented – Bring specific element within the application onto full screen.
The Silverlight application contained several controls, each having its own full screen mode, consider the following UI -
These are two controls which can be practically anything. A real-life example would be media players. Assume you needed to support multi media players and provide the functionality of viewing each in full screen mode.
As mentioning in the beginning, setting the application to full screen is not enough. It will simply display the entire application in full screen, whereas what we really is to display the control itself onto full screen.
The trivial solution that comes into mind is that when the full screen button is pressed in each control, we adjust the UI to include only that control on top of everything and set the application to be in full screen.
That will work, however, it has its issues -
- What if we want to package this control? This means we can’t modify the application Ui when the button is pressed since we have no idea where and how this control was placed.
- In this case, we may think about raising an event and let the application adjust the UI properly. The problem with that is that the application needs to write a lot of code in order to make our full screen feature work.
- This solution is inherently coupled to the UI. changes to the UI structure will require changes to that code as well
Obviously, I wanted to find a better, more encapsulated and reusable solution.
I decided to write a helper class to provide this functionality seamlessly and as simple as:
myControl.ToggleElementFullScreen();
The main design is to move the element to a popup on top of the entire root visual. Obviously, there’s more logic into it such as moving the element, sizing, preserving size-related information since when exiting the full screen requires to move the element back to its original state and position. Plus, I had to take care of when the user exits the full screen using the Escape key.
I’m very happy with the final solution, it is clean, easy and reusable and acts very similar to how the ChildWindow works.
I attached the project, make sure you enter the specific post page in order to see the link.
Things to Note:
- My class takes care of placing the element as needed, but it is still your responsibility to make your view stretchable on the entire available size. Otherwise, the element will not fill the entire area.
- Since the implementation needs to remove the element from where it is placed and move it to my popup, I currently support that the element can be a child/content of the following: Panel, ContentControl, UserControl, and Popup.
CodeProject