How to choose from Viewstate, SessionState, Cookies and Cache

Problem with Web Applications

Web Applications are natively statesless, means once a web page renders from server to client, nothing remains on server and the next time user submits the page you have to create the page again.
Solutions in ASP.NET

ASP.NET provides multiple simple solutions to this problems like:

1- Viewstate
2- Session Variables
3- Application Variables
4- Cache
5- Cookies


Now the question arises that when to use what?


1- Viewstate

Viewstate is a hidden fields in an ASP.NET page, contains state of those controls on a page whose "EnableViewstate" property is "true".
You can also explicitly add values in it, on an ASP.NET page like:
Viewstate.Add( "TotalStudents", "87" );
Viewstate should be used when you want to save a value between diferent roundtrips of a single page as viewstate of a page is not accessible by another page.
Because Viewstate renders with the page, it consumes bandwith, so be careful to use it in applications to be run on low bandwith.

2- Session Variable

Session variables are usually the most commonly used.
When a user visits a site, it's sessions starts and when the user become idle or leave the site, the session ends.
Session variables should be used to save and retrive user specefic information required on multiple pages.
Session variables consumes server memory, so if your may have a huge amount visiters, use session very carefully and instead of put large values in it try to put IDs and references


3- Application variables

Application variables are shared variables among all users of a web application
Application variables behave like static variables and they are substitute of static variables as static variables are stateless in web applications
Only shared values should be persisted in Application variables, and as soon as they are not in use they should be removed explicitly.

4- Cache

Cache is probably the least used state feature of ASP.NET.
Cache is basically a resource specific state persistence feature, means unlike session it stick with resource instead of user, for instance: pages, controls etc.
Cache should be used or frequently used pages, controls, and data structures
Data cache can be used to cache frequently used list of values e.g. list of products


6- Cookies

Cookies are some values saved in browsers for a particular website o publicly accessible
The purpose of cookies is to help websites to identify visitors and retrieve their saved preferences
Cookies are also used to facilitate auto login by persisting user id in a cookie save in user's browser
Because cookies have been saved at client side, they do not create performance issues but may create security issues as they can be hacked from browser


Finally remember the following points on your finger-tips:

1- Viewstate is bandwidth hungry
2- Session variables are memory hungry as per number of users
3- Applications variables are shared
4- Cache is memory hungry as per number of resources
5- Cookies are the least secure

Why Patterns Suck

It was surprising for me to hear people saying "Patterns suck", I wanted to know why people hate these precious guidelines to save us to reinvent the wheel and let us to use it.

After few days I had to work with some arrogant people who known to be pattern-lovers. Having a lot of technical knowledge, they used to remember the names of patterns and writers on finger tips. You can talk to them for not just hours but for days. In the first place I admired them and found myself among great people.

Then I found something strange, besides all their technicalities they had very few success stories so what was the problem?

I had started observing the causes of their failure. In the mean time I had to design an architecture for a coming enterprise project. I started scaffolding by enhancing and optimizing my legacy libraries and framework with my team. I asked those people to review my approach to let me become foolproof.

Geeks love technicalities so I got a prompt response and they started highlighting the weaknesses, I was very glad to see that I got a chance to improve. But unexpectedly most of the issues identified are as follows:

Geeks: Aren’t you using Hibernate?
Me: Nope, I wanna utilize the objects which are optimized for and provided by the technology and I have tested them in complex applications.

Geeks: These objects are mess?
Me: Why?

Geeks: Because these are not open-sourced

Me: I admire the benefits of open source but these object are rich, free, built-in, tested and performing well in enterprise applications. I do not very often use them but I found them very useful in such kind of applications

Geeks: You incorrectly applied this pattern; let me show you the documentation.
Me: This pattern like other patterns have different applications, I am following this approach because it performs well in this scenario. This flexibility is also allowed by some experts.

Geek: No, patterns should be followed as is. They are not to be changed for performance or whatever. And remember enterprise applications, built on great technologies like EJB, looks graceful even if they are not enough performant.

Geek: Increase your number of layers like we have did in that application. You have not decoupled enough.

Me: Yes previously I do have the same number of layers but I found it as an overkill so I modified this framework for medium-sized performance-hungry applications.

Geek: And why did you coupled these two major tiers, this is an unacceptable violation of N-Tier Architecture

Me: No, these are still two different layers, but I am keeping them in a single project during development as most of the developers are working on both layers. They still can be deployed on different servers.

Geek: I’m still not satisfied, it is not recommended by our gurus and we follow them because we know they are the best.

Me: They might have recommended it for some different type of project and this approach may be suitable that particular scenario.

Geek: We found their practices the best in all type and size of projects, whatever, it’s not that simple you think it is, you have to add a lot more.


And then I found the key: why people hate patterns, got my point?

Soon, at the same location, I have met with people who say:
"We are successful because we don't develop frameworks and implement patterns. We solve problems, not create”

This kind of concept are erected against the religiousness of pattern-lovers. I was so excited to know that which people are most successful among them.

But what I found was the worst


How to get the worst of all the worlds
The story of ancient war

Software Developers : The Pattern Lovers
Slogans:
Reinvent the wheel
Complexity is honour
Best is always the best
Think out-of-the-box never look inside

Whenever company gets a project the developers are in search of well-hyped patterns and practices. Whatever the projects require, whatever the timelines are, they follow impressions, seeking complexities to passionate their lives. The problem is they want to combine the universal truths they get from their gurus, with the hypes. They get the compliance in few of the cases. It becomes a routine that start with complexity and when you stuck, let the things fly.
They often suggest the solutions they think they should learn. According to their point of view: software projects are to create a difference, even if the project fails, even if they do not add any value, if they implement state-of-the-art technologies, they consider it success.


Software support: the delivery people
Slogans:
We deliver
Quality is a fantasy, don’t talk about it
Ad-hocism
Research is a synonym of time-wasting;
Pattern sucks

Fortunately some of the projects who comply with hyped patterns and rigid practices succeeded to achieve the timelines, thanks fortune. And now the support people are ready to show their quick solutions. They’ll show that the tasks completed by the developers in month was just a matter of days. Thanks to encapsulation; no one knows what’s inside J

Till the day the application is safe from the quick solutions of support staff, it shows some stability. And once it gets the first JUGAR—synonym for a careless ad-hoc solution in Urdu language—the application becomes more addicted to their JUGARs and provides more options for support people to prove their problem solving skills.
[To be continue]

Java or DotNet, how to choose among?

1. Requirement of application portability
If your application requires portability on different platform, Java has more options than .NET.

2. Requirement of extent of Scalability
Java starts with scalability while .NET starts with simplicity, if you can handle the complexity you can enjoy the scalability of Java. Otherwise you can be stuck in between.

3. Size and budget of the solutions
You also have to consider the size and budget of your solution, If you are developing a small application neither of these suits you enough--ignoring all other factors--you may have other cheap alternatives like InfoPath, MS Access, Excel Applications

4. Complexity of application (processes, transactions, interfaces, integration etc.)
Business applications comprise of complex in-memory transactions are better to be built on Java, thanks to application servers. .Net is still lacking mature and reliable in memory transacion handling. Database driven applications not having complex business processes usually cost less on .Net.

5. Availability of development skills and infrastructure.
If you don't have experienced and knowledgeable resources, Java can become a may become a hard nut for you.

6. Integration with Legacy systems.
Usually a vendor's approach is to sick with it's own products, or to prioritize at least. Though Microsoft provides integration with it's own legacy systems but to motivate people to move on earlier product, they often disclaim to support for a long time. Being managed by people, Java gets more marks in this regard.

7. License cost vs. Development cost.
Usually Java brings with more free and open source options as well as more development and integration cost. While .NET brings with easy development and integration with less free and open source options. So prepare for greater development cost in Java and greater license cost in .NET.

Trends I observer during conducting interviews

At my workplace, I am also responsible for attraction and retention of software developers. During interviews, I conducted, I observer following trends:

• In most of the organizations the hierarchy is

CTO/Dept. Head >> PM >>TL >> SSE >> SE

• Most of the Resource Managers (Team Leads) are planning to become Project Manager
  
• Senior technical positions like Architect, are not available for technical people
  
• Senior Software Developers are planning to become Team Leads to get raise in benefits instead of focusing on scarce senior technical positions
  
• Most of the resources have working experience of small-size offshore projects, they don't have the experience and expertise of Enterprise Solutions
  
• Most of the fresh graduates prefer better salary on career growth & learning
  
• After initial 2 years, having some quick job-switches, some of them realize that if they could learn, they could earn more. Then they change their mind to prefer learning over adhoc monitory benefits
  
• It's becoming general perception among software industry that to become a project manager is the shortest path to get fat salaries
  
• Computer Science Graduates are preferring to get admission in MBA instead of MS
  
• In MS(Computer Science), Project Management is becoming a buzzword
  
• It seems that in few years, we will have greater number of Managers and lesser number of technical resources, at least in software development
  

Disclaimer: This is my personal observation, not neccessarily true.