As developers we are quite often put in a situation of trying to find the right solution of a currently emerging problem. The immense information we have at hand (eyes) with internet might not always be useful, instead if you think about it, it can be in a way a bit wicked… Wicked so that it makes us copy and reuse ready-made fragments which leads to our tasks being finished as soon as possible. What I am trying to imply is that if we want to reuse our own knowledge, we should try to be aware of the fundamentals of the technologies we utilize.
Some of the basic, yet important aspects of ASP.NET state management a developer should have in mind:
- Try to see the whole picture of state management in web applications in general (cookies, hidden fields, parameterized addresses)
- Then above all – know a page lifecycle. It comes very handy when you wonder what is executed first, the button click event handler or the page load one :).
- What comes next is see what goodies we have in ASP.NET in particular – view state, application state, session state
- Last - you can check how to manipulate request/response objects in .NET
A presentation from a Sofia University course referring to the above matters: ASP.NET-State-Management.pdf (12.48 mb)
…and the demos for it: State-Management-Demos.rar (44.68 kb)
I intend to start something of a personal initiative and upload some materials on talks I held. Hopefully they can be useful to others. One of the courses I eagerly participated in was on the subject of Design Patterns a couple of years ago.
Façade was the first topic I had to cover and the talk was very well accepted by the students in Sofia University, even though I had very little experience in public speaking back then. Thinking about it - good preparation plus some funny moments played the main role for that. As for the more technical aspect of it, I will try to lead you through the main idea of the pattern:
From time to time it might happen that we come across a complicated system (in terms of being highly coupled) and we should somehow plug into it and use its features. God forbid the system was not developed by us, and then the misery is doubled :). Let me illustrate what I mean:
If we are in the tough position of creating the client, we will bump into:
- the complexity of such a base system;
- the high coupling of the classes;
- the difficulties we hardly can foresee in supporting such a monster :).
So what we can do is, expose only the functionality we need for our client and in a way – forget about the rest of the hairy base system, reshaping the sketch like this:
In such way we can create a separate level of abstraction, which is much more easily “absorbable” by us developers.
Here is the presentation FacadePattern.pdf and the demos FacadeDemos.zip. Having in mind the source code is very minimalistic example of a Façade pattern implementation – enjoy :).