Machine Learning and Deep Learning Basics

10 Sep

1. Introduction

    Artificial Intelligence is a broad field, but most of its modern breakthroughs stem from Machine Learning (ML) and its subfield Deep Learning (DL).

      • Machine Learning focuses on algorithms that learn patterns from data and improve with experience.

      Deep Learning is a specialized subset of ML that uses neural networks with many layers to process large, complex data like images, speech, and text.

      2. Concepts & Explanations

      Machine Learning Paradigms

      Machine Learning (ML) is a core subfield of Artificial Intelligence that enables systems to learn from data and improve over time without being explicitly programmed for every task. In ML, models identify patterns and make decisions based on training data.

      Machine learning is the scientific study of algorithms and statistical models that computer systems use to effectively perform a specific task without using explicit instructions, relying on patterns and inference instead.

      Building a model by learning the patterns of historical data with some relationship between data to make a data-driven prediction

      General Architecture of Machine Learning: 

      Business understanding: Understand the given use case, and also, it’s good to know more about the domain for which the use cases are built.

      Data Acquisition and Understanding: Data gathering from different sources and understanding the data. Cleaning the data, handling the missing data if any, data wrangling, and EDA( Exploratory data analysis).

      Modeling: Feature Engineering – scaling the data, feature selection – not all features are important. We
      use the backward elimination method, correlation factors, PCA and domain knowledge to select the
      features.
      Model Training based on trial and error method or by experience, we select the algorithm and train with
      the selected features.
      Model evaluation Accuracy of the model , confusion matrix and cross-validation.
      If accuracy is not high, to achieve higher accuracy, we tune the model…either by changing the algorithm
      used or by feature selection or by gathering more data, etc.
      Deployment – Once the model has good accuracy, we deploy the model either in the cloud or Rasberry
      Pi or any other place. Once we deploy, we monitor the performance of the model. if its good…we go live
      with the model or reiterate the all process until our model performance is good.
      It’s not done yet!!!
      What if, after a few days, our model performs badly because of new data. In that case, we do all the
      process again by collecting new data and redeploy the model.

      ML can be classified into 3 main paradigms:

      Supervised Learning : Here the machine learns from  labeled data.

      Learn from labeled data (input + output).

      Example: Predicting house prices from square footage.

      Algorithms: Linear regression, decision trees, support vector machines.

      In supervised learning, the model is trained on a labeled dataset — where each input is paired with the correct output. The goal is to learn a mapping from inputs to outputs, enabling the model to make accurate predictions on new, unseen data.

      Supervised learning is classified into two categories of algorithms:
      Classification: A classification problem is when the output variable is a category, such as “Red” or “blue”, “disease” or “no disease”.
      Regression: A regression problem is when the output variable is a real value, such as     “dollars” or “weight”.

      Examples:

      •  Predicting house prices (input: size, location; output: price)
      • Email spam detection (input: email content; output: spam/not spam)
      •  Image classification (input: image pixels; output: object label)

      Common Algorithms:

      • Linear Regression
      • Logistic Regression
      • Decision Trees
      • Support Vector Machines (SVM)
      • Neural Networks

      Use Cases:
                              1. Fraud detection
                              2. Sentiment analysis
                              3. Medical diagnosis

      1. Unsupervised Learning
        • Learn from unlabeled data, finding patterns and structure.
        • Example: Grouping customers into segments based on shopping behavior.
        • Algorithms: K-means clustering, PCA (Principal Component Analysis).

      In unsupervised learning, the model is given input data without labels. The goal is to find hidden patterns, groupings, or structures within the data.

      An unsupervised model, in contrast, provides unlabelled data that the algorithm tries to make sense of by extracting features, co-occurrence and underlying patterns on its own.

      Examples:

      •  Clustering users based on browsing behavior
      •  Dimensionality reduction for data visualization
      •   Anomaly detection in network traffic

      Common Algorithms:

      • K-Means Clustering
      • Hierarchical Clustering
      • Principal Component Analysis (PCA)
      • Autoencoders

      Use Cases:

      • Market segmentation
      • Recommender systems
      • Data compression

      Reinforcement Learning (RL)

      An agent learns by interacting with an environment, receiving rewards or penalties.

      Example: Training a robot to walk, or AI to play chess.

      Reinforcement Learning (RL) is a goal-directed learning paradigm in which an agent learns to make decisions by interacting with an environment. It receives feedback in the form of rewards or penalties based on its actions and aims to maximize cumulative reward over time.

      Reinforcement learning is less supervised and depends on the learning agent in determining the output solutions by arriving at different possible ways to achieve the best possible solution.

      Examples:

      Teaching a robot to walk,

      Training an AI to play chess or Go

      Optimizing delivery routes

      Key Concepts:

      Agent: The learner or decision-maker

      Environment: Everything the agent interacts with

      Reward Signal: Feedback for good or bad behavior

      Policy: The strategy the agent uses to make decisions

      Use Cases:

      • Game AI
      • Robotics control
      • Dynamic pricing
      • Personalized recommendations

      💡 Analogy:

      • Supervised → A teacher provides answers to all practice problems.
      • Unsupervised → A student tries to find patterns in problems without answers.
      • Semi-supervised → Some answers are given, the rest must be figured out.

      Reinforcement → Learning by trial and error, like a baby learning to walk.

      Traditional ML vs. Deep Learning

      • Traditional ML
        • Relies on hand-crafted features (e.g., edge detectors in images).
        • Works well for small-to-medium datasets.
        • Examples: Decision Trees, Random Forests, SVMs.
      • Deep Learning
        • Learn features automatically from raw data using neural networks.
        • Requires large datasets and high computational power.
        • Excels in complex tasks (e.g., speech recognition, image generation).

      📘 Diagram (text description):

      • Traditional ML pipeline: Raw Data → Feature Engineering → Model Training → Prediction.
      • Deep Learning pipeline: Raw Data → Neural Network (learns features + model) → Prediction.

      2.3 Neural Networks: Architecture & Learning

      A neural network is inspired by the human brain:

      • Neurons → simple units that take input, apply a function, and pass output.
      • Layers →
        • Input layer (data features).
        • Hidden layers (transformations).
        • Output layer (prediction/classification).

      💡 Analogy: Imagine a bakery:

      • Input layer → Ingredients.
      • Hidden layers → Baking process (mixing, heating, decorating).
      • Output layer → Final cake.

      2.4 Core Concepts

      • Activation Functions: Decide how much signal passes through a neuron.
        • Examples: Sigmoid, ReLU, Tanh.
      • Loss Function: Measures how far predictions are from true values.
        • Example: Mean Squared Error for regression, Cross-Entropy Loss for classification.
      • Optimizers: Algorithms that adjust model parameters to minimize loss.
        • Example: Gradient Descent, Adam optimizer.
      • Backpropagation: The process of propagating errors backward through the network to update weights.

      2.5 Evaluation Metrics

      Different tasks require different evaluation metrics:

      • Classification: Accuracy, Precision, Recall, F1-score.
      • Regression: Mean Squared Error (MSE), R² score.
      • Generative models (later chapters): BLEU score, Perplexity, Fréchet Inception Distance (FID).

      2.6 Bias, Fairness & Ethics

      AI models can inherit bias from data:

      • Example: A recruitment model trained on biased data may unfairly reject female candidates.
      • Fairness techniques: Data balancing, bias detection, and fairness-aware algorithms.
      • Ethics: Transparency, accountability, and ensuring AI benefits society.

      3. Use Cases & Applications

      • Healthcare: Predict disease risks, detect cancer from medical scans.
      • Finance: Credit scoring, fraud detection.
      • Education: Personalized learning systems.
      • Retail: Customer segmentation, demand forecasting.
      • Transportation: Autonomous driving using deep learning for object detection.

      4. Algorithms & Techniques

      Let’s explore two practical ML approaches:

      4.1 Supervised Learning Example (Classification)

      # Classifying iris flowers using scikit-learn

      from sklearn.datasets import load_iris

      from sklearn.model_selection import train_test_split

      from sklearn.tree import DecisionTreeClassifier

      from sklearn.metrics import accuracy_score

      # Load dataset

      iris = load_iris()

      X, y = iris.data, iris.target

      # Split into train and test sets

      X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

      # Train decision tree

      clf = DecisionTreeClassifier()

      clf.fit(X_train, y_train)

      # Predictions

      y_pred = clf.predict(X_test)

      print(“Accuracy:”, accuracy_score(y_test, y_pred))

      4.2 Deep Learning Example (Neural Network for Digit Recognition)

      import tensorflow as tf

      from tensorflow.keras.datasets import mnist

      from tensorflow.keras.models import Sequential

      from tensorflow.keras.layers import Dense, Flatten

      from tensorflow.keras.utils import to_categorical

      # Load dataset

      (X_train, y_train), (X_test, y_test) = mnist.load_data()

      X_train, X_test = X_train / 255.0, X_test / 255.0  # normalize

      y_train, y_test = to_categorical(y_train), to_categorical(y_test)

      # Build neural network

      model = Sequential([

          Flatten(input_shape=(28, 28)),

          Dense(128, activation=’relu’),

          Dense(10, activation=’softmax’)

      ])

      # Compile and train

      model.compile(optimizer=’adam’, loss=’categorical_crossentropy’, metrics=[‘accuracy’])

      model.fit(X_train, y_train, epochs=5, validation_data=(X_test, y_test))

      # Evaluate

      loss, accuracy = model.evaluate(X_test, y_test)

      print(“Test Accuracy:”, accuracy)

      5. Case Study / Mini-Project

      Mini-Project: Spam Email Classifier

      We’ll build a simple spam detection model using Naive Bayes.

      from sklearn.model_selection import train_test_split

      from sklearn.feature_extraction.text import CountVectorizer

      from sklearn.naive_bayes import MultinomialNB

      from sklearn.metrics import classification_report

      # Example dataset

      emails = [“Win money now!!!”, “Meeting at 3 pm”, “Get cheap loans instantly”, “Lunch tomorrow?”]

      labels = [1, 0, 1, 0]  # 1 = spam, 0 = not spam

      # Vectorize text

      vectorizer = CountVectorizer()

      X = vectorizer.fit_transform(emails)

      # Train-test split

      X_train, X_test, y_train, y_test = train_test_split(X, labels, test_size=0.25, random_state=42)

      # Train Naive Bayes classifier

      clf = MultinomialNB()

      clf.fit(X_train, y_train)

      # Predictions

      y_pred = clf.predict(X_test)

      print(classification_report(y_test, y_pred))

      ➡️ This shows how supervised learning can classify emails as spam or not spam.

      6. Summary

      We explored practical examples: iris classification, digit recognition, and spam detection.
      Machine Learning enables computers to learn patterns from data.

      Main paradigms: supervised, unsupervised, semi-supervised, reinforcement learning.
      Traditional ML relies on feature engineering; Deep Learning learns features automatically.
      Key concepts: activation functions, loss functions, optimizers, and backpropagation.
      Evaluation metrics help measure model performance.
      Ethical challenges (bias, fairness) must be addressed.

      ➡️ (Above content is taken by my best selling book Generative AI & Machine Learning)

      Tags: , , , ,

      Fast API Project Structure

      14 Aug

      FastAPI project structure that incorporates multiple design patterns including:

      • Dependency Injection
      • Repository Pattern
      • Service Layer
      • Strategy Pattern
      • Factory Pattern
      • Observer Pattern
      • Builder Pattern
      • Domain-Driven Design (DDD) principles

      🧱 Project Structure

      fastapi_project/
│
├── app/
│   ├── main.py                  # FastAPI app entry point
│   ├── config.py                # App configuration
│   ├── dependencies/            # DI providers
│   │   ├── db.py
│   │   ├── auth.py
│   │   └── __init__.py
│   │
│   ├── models/                  # Pydantic models
│   │   ├── user.py
│   │   ├── request.py
│   │   └── __init__.py
│   │
│   ├── domain/                  # Domain models (DDD)
│   │   ├── entities/
│   │   │   ├── user_entity.py
│   │   │   └── __init__.py
│   │   └── __init__.py
│   │
│   ├── repositories/            # Repository pattern
│   │   ├── user_repository.py
│   │   └── __init__.py
│   │
│   ├── services/                # Business logic (Service Layer)
│   │   ├── user_service.py
│   │   └── __init__.py
│   │
│   ├── strategies/              # Strategy pattern
│   │   ├── auth/
│   │   │   ├── jwt_strategy.py
│   │   │   ├── oauth_strategy.py
│   │   │   └── __init__.py
│   │   └── __init__.py
│   │
│   ├── factories/               # Factory pattern
│   │   ├── service_factory.py
│   │   └── __init__.py
│   │
│   ├── observers/               # Observer pattern
│   │   ├── event_manager.py
│   │   └── __init__.py
│   │
│   ├── builders/                # Builder pattern
│   │   ├── report_builder.py
│   │   └── __init__.py
│   │
│   ├── middleware/              # Custom middleware
│   │   ├── logging_middleware.py
│   │   └── __init__.py
│   │
│   ├── routes/                  # API routes
│   │   ├── user_routes.py
│   │   └── __init__.py
│   │
│   └── utils/                   # Utility functions
│       ├── helpers.py
│       └── __init__.py
│
├── requirements.txt
└── README.md

      🧩 How Patterns Fit Together

      PatternFolderPurpose
      Dependency Injectiondependencies/Inject DB, auth, config
      Repositoryrepositories/Abstract DB access
      Service Layerservices/Business logic
      Strategystrategies/Pluggable auth or processing logic
      Factoryfactories/Create services based on config
      Observerobservers/Event-driven notifications
      Builderbuilders/Construct complex objects
      DDDdomain/Domain entities and aggregates

      Conclusion: In a FastAPI project, you can implement several software design patterns to improve modularity, scalability, and maintainability. Here’s a categorized overview of the most relevant patterns and how they apply to FastAPI

      Understanding the Evolution: Generative AI, AI Agents, and Agentic AI

      12 Aug

      Introduction

      As artificial intelligence continues to evolve, it’s essential to distinguish between three foundational yet distinct paradigms: Generative AI, AI Agents, and Agentic AI. While these concepts are closely related, each represents a different level of autonomy, complexity, and capability. This guide breaks down their core differences, practical applications, and how they build upon one another.

       

      1. Generative AI: Creating Content on Demand

      What It Is

      Generative AI refers to models—like large language models (LLMs) and image generators—that produce original content based on patterns learned from massive datasets. These models are trained on diverse data (text, images, audio, video) and contain billions of parameters.

      How It Works

      Generative AI is reactive: it responds to user prompts without initiating actions or managing tasks. For example, when prompted to “write a poem about data science,” the model generates a poem but doesn’t decide to write one on its own.

      Key Features

      • Trained on large, multimodal datasets

      • Generates text, images, audio, or video

      • Requires prompt engineering to guide output

      • Examples: OpenAI’s GPT-4, Meta’s LLaMA 3

      • Supported by tools like LangChain, LlamaIndex, and Grok

      2. AI Agents: Task-Oriented Intelligence

      What They Are

      AI agents extend generative AI by adding autonomy and interactivity. They can perform specific tasks by integrating with external tools and APIs, making them more dynamic and useful in real-world applications.

      Why They Matter

      LLMs alone can’t access real-time or private data. AI agents solve this by making tool calls—requests to external systems—to fetch current or specialized information.

      Example Workflow

      1. User asks a question.

      2. Agent checks if the LLM can answer.

      3. If not, it calls an external API (e.g., for today’s news).

      4. It processes the response.

      5. It delivers a final answer to the user.

      Key Features

      • Built on LLMs with external tool integration

      • Can retrieve real-time or private data

      • Perform single, well-defined tasks

      • Still reactive, but with enhanced capabilities

      • Act autonomously within defined boundaries

      3. Agentic AI: Orchestrating Complex Workflows

      What It Is

      Agentic AI represents the next level—multi-agent systems that collaborate to complete complex, multi-step workflows. Each agent specializes in a subtask, and together they operate like a coordinated team.

      Use Case: YouTube to Blog

      An agentic AI system might:

      1. Extract a transcript from a YouTube video

      2. Generate a blog title

      3. Write a summary and description

      4. Compose a conclusion

      Each step is handled by a different agent, and outputs are passed between them to produce a polished blog post.

      Key Features

      • Multiple agents working in sequence or parallel

      • Each agent handles a specific subtask

      • Enables end-to-end automation of complex workflows

      • Supports human feedback for refinement

      • Adds adaptability and robustness through collaboration

      4. Comparative Summary

      Minimize image
      Edit image
      Delete image

      5. Strategic Implications

      Generative AI

      Ideal for creative content generation, but limited by its reactive nature. Success depends heavily on prompt quality.

      AI Agents

      Bridge the gap between static models and dynamic applications. Useful in domains like customer service, analytics, and decision support.

      Agentic AI

      Best suited for automating complex, multi-step processes. Aligns with real-world workflows and supports scalability, adaptability, and human oversight.

      Conclusion

      Understanding the distinctions between generative AI, AI agents, and agentic AI is essential for anyone working with modern AI systems. From content creation to autonomous task execution and workflow orchestration, these paradigms represent a clear evolution in capability and complexity. By choosing the right approach, organizations can unlock new levels of efficiency, creativity, and intelligence in their AI-driven solutions.

      Understanding Generative AI: Key Concepts and Use Cases

      10 Aug

      Generative AI is like a magic artist. It learns from a lot of examples and then uses that learning to create new things that fit the patterns it learned. It’s like having a creative computer friend that can make up new music, art, or even stories!

      Generative AI (GenAI) is a type of artificial intelligence that is used to generate new data or content from existing data. It can be used to create new text, images, videos, and other forms of data.

      Large Language Models are a type of generative AI that use deep learning algorithms to generate natural language from large datasets. They are used for a variety of applications such as natural language processing, machine translation, and question answering.

      Large Language Modal (LLM) Use Cases

      Large Language Models (LLMs) like GPT-4 have a wide range of use cases across various industries and domains. Here are some prominent use cases:

      1. Content Generation:
        • Writing articles, blog posts, and reports.
        • Creating marketing copy and advertising content.
        • Drafting emails and messages.
      2. Conversational Agents:
        • Developing chatbots and virtual assistants.
        • Enabling natural language interactions in customer support.
      3. Language Translation:
        • Translating text between different languages.
        • Facilitating real-time language translation for travelers and businesses.
      4. Text Summarization:
        • Summarizing lengthy documents, research papers, and articles.
        • Generating concise overviews for news stories.
      5. Code Generation:
        • Writing code snippets in various programming languages.
        • Assisting developers in automating repetitive tasks.
      6. Creative Writing:
        • Crafting poetry, stories, and screenplays.
        • Generating unique content for artistic purposes.
      7. Educational Tools:
        • Providing explanations and answers for students’ questions.
        • Offering tutoring and learning assistance.
      8. Data Analysis:
        • Assisting in data interpretation and insights generation.
        • Simplifying complex statistical information for non-experts.
      9. Medical and Scientific Applications:
        • Analyzing medical records and generating clinical reports.
        • Assisting researchers in data analysis and hypothesis generation.
      10. Legal and Compliance:
        • Drafting legal documents, contracts, and agreements.
        • Offering legal research and analysis support.
      11. Personal Assistants:
        • Managing calendars and scheduling appointments.
        • Sending reminders and setting alarms.
      12. Gaming and Entertainment:
        • Generating in-game dialogues and narratives.
        • Creating interactive storytelling experiences.
      13. Accessibility Support:
        • Assisting individuals with disabilities in communication and information access.
      14. Market Research and Analysis:
        • Extracting insights from social media and online discussions.
        • Analyzing consumer sentiment and trends.
      15. Simulations and Training:
        • Simulating characters and scenarios for training purposes.
        • Enhancing virtual reality experiences.
      16. Human Resources:
        • Assisting in resume writing and job description creation.
        • Conducting initial candidate screenings.
      17. Innovative Interfaces:
        • Enabling voice-controlled applications and devices.
        • Powering interactive storytelling experiences.
      18. Knowledge Management:
        • Assisting in documentation, note-taking, and knowledge retrieval.
        • Organizing and summarizing research materials.
      19. Automated Social Media:
        • Generating social media posts and engagement.
        • Providing suggestions for content creation.
      20. Ethical and Societal Debates:
        • Engaging in philosophical discussions and debates on ethical issues.
        • Promoting critical thinking and diverse perspectives.

      These are just a few examples of the diverse applications of Large Language Models. As the technology evolves, new use cases will likely continue to emerge.

      What is a Foundation Model?

      A foundation model is a large-scale language model trained on vast amounts of data and designed to perform a wide range of tasks. These models are evaluated using diverse prompts across many scenarios, enabling them to generalize effectively and adapt to various downstream applications such as text generation, summarization, translation, and more.

      Key Characteristics of GPT-4 Foundation Model

      1. Scale and Architecture

      GPT-4 is built using a Mixture of Experts (MoE) architecture, comprising 1.76 trillion parameters across 120 layers  This is more than 10 times the size of GPT-3. The model routes inputs through a subset of 2 out of 16 expert networks per forward pass, optimizing performance and cost.

      2. Training Data

      GPT-4 was trained on approximately 13 trillion tokens, sourced from a mix of datasets including CommonCrawl, RefinedWeb, and other curated sources. It also includes data from platforms like Twitter, Reddit, YouTube, and a large collection of textbooks and code repositories 

      3. Generative Capabilities

      GPT-4 is a generative model, capable of producing original, contextually relevant content. It can:

      • Write essays and articles
      • Generate computer code
      • Create charts and websites from text descriptions
      • Compose emails, summaries, and more

      4. Human-like Interaction

      GPT-4 maintains context across interactions, remembering previous prompts and adapting to new inputs. This enables natural, conversational exchanges, similar to human dialogue.

      5. Adaptability

      Through continuous interaction, GPT-4 learns patterns and relationships, improving its responses over time. This adaptability reduces the need for retraining for each new task.

      6. Self-supervised Learning

      GPT-4 uses self-supervised learning, allowing it to train on unlabeled data. This approach enables the use of massive raw datasets, shifting the focus from manual labeling to computational scalability.

      7. Multi-modal Learning

      GPT-4 supports multi-modal inputs, including text and images, enabling it to interpret and generate content across different data types. This mimics human-like sensory learning and expands its utility.

      8. Few-shot and Zero-shot Learning

      GPT-4 excels at few-shot and zero-shot learning, allowing it to perform tasks with minimal or no specific training examples. This makes it highly versatile and efficient for rapid deployment.

      What are Prompts?

      Generative AI models primarily interact with users through text-based input. You provide instructions or requests via a text interface, and the model works to fulfill them. In general, this input is called a prompt.

      For large language models (LLMs) like GPT-4 or ChatGPT, prompts can range from straightforward questions (e.g., “Who is the president of the India?”) to complex tasks (e.g., “Analyze the impact of globalization on the development of third-world countries, focusing on economic, political, and social aspects.”). Prompts may also include various forms of data—even files such as CSVs—or be as casual and open-ended as “Tell me a joke. I’m feeling down today.”

      What is Prompt Engineering?

      Prompt Engineering is a relatively new field focused on creating and refining prompts to make the most effective use of language models (LMs) across various applications and research areas. Developing these skills helps users understand both the strengths and limitations of large language models (LLMs).

      It is applied by:

      • AI professionals – converting tasks into prompt-based datasets that a model can be trained on.
      • Researchers – enhancing LLM performance on a range of tasks from question answering to arithmetic reasoning.
      • Developers – designing reliable prompting techniques to connect LLMs with other tools.

      Types of Writing Prompts

      1. Instruction – Directly tells the model what to do.
        Example: “Write a story about a poor, hardworking farmer who becomes a successful businessman through determination.”
      2. Continuation – Provides a partial sentence or text for the model to complete.
        Example:
        Prompt: “The following is a step-by-step process for preparing chicken salad. Step 1: Cut the veggies –”
        AI Response: “Step 2: Toss the chicken nuggets. Step 3: Mix everything together.”
      3. In-Context Learning (ICL) – Supplies a few examples in the prompt, enabling the model to learn from them and apply the same logic to new inputs.
        Example: Providing short passages with labeled topics so the AI can classify a new passage correctly.

      Delimiters in Prompts

      A delimiter is a symbol or marker used to separate sections within a prompt. It:

      • Organizes information for clarity.
      • Marks where tasks or sections begin and end.
      • Helps the AI focus on specific parts of the prompt.
      • Often works with a stop sequence (e.g., \n, ###, ===, ::).

      Benefits of Delimiters

      • Improved Control – Focus the model on the right section of text.
      • Multi-Turn Conversations – Separate user inputs from AI responses for coherent dialogues.
      • Task Separation – Divide multiple tasks (e.g., summarization, translation) within one prompt.
      • Context Preservation – Maintain conversation flow in interactive sessions.
      • Simultaneous Prompts – Handle multiple requests in one input for batch responses.
      • Customization – Use custom delimiter tokens to suit specific needs.
        Example:
        Task1: Summarize === “Healthy ecosystems require a variety of species…”
        Task2: Translate === “Hello, how are you?”
        Here, === clearly separates tasks so the AI can respond to each one independently.

      Elements Of Prompts

      A prompt can include several components, but not all are always necessary. The structure and combination of these elements should be tailored to the specific task or objective.

      prompt_component

      Key processes in prompt engineering

      There are three main processes to follow in prompt engineering:

      Types Of Prompts

      1. Open Ended Prompts: An Open-ended prompt requires the model to generate an answer with few constraints or options given by the prompt.

      open type

      2. Closed Type: A Closed-ended prompt asks the model to complete an action on a text, given specific parameters and instructions.

      Prompt TypeDescriptionExample
      RewriteModify the existing content to suit different variations such as form, tone, persona, etc.Infuse a cheerful tone into this blog.
      ExtractExtract a specific block of text verbatim from the given content.Identify the sentence where the doctor recommended the treatment plan.
      SummarizeInvolves summarizing a block of text while avoiding the use of exact wording from the original text.Summarize the key tasks from this conference report.
      Closed ended QAThis entails extracting information from a written text, which can be either extractive or abstractive in nature.How frequently did Alice discuss her new project in this conversation?
      Close ended classificationRequesting the model to categorize a given text based on a provided selection of classes.Categorize the content as either Travel, Fashion, or Entertainment.

      Designing prompts for different tasks

      A prompt can contain information like the instruction or question you are passing to the model and include other details such as inputs or examples. Today’s LLMs can perform all kinds of advanced tasks that range from text summarization, mathematical reasoning, to code generation. Well-crafted prompts can be used to perform all types of interesting and different tasks.

      design prompts

      Note: This is just very beginning introduction of GenAI. To complete content and knowledge you may DM me on er.sandeepp@gmail.com directly or you may join my live sessions for the same.

      You may join my WhatsApp group for further notification about boot camp : https://chat.whatsapp.com/JTnI8LL9FgrI4G8Qcm68fq

      Tags: , , , , ,

      Be careful! Consuming These 4 Vegetables And Organic products In Crude Structure Might Have Extreme Wellbeing Perils

      10 Aug

      Certain crude products of the soil are home to E.Coli microorganisms or tapeworms and their eggs that can cause serious medical problems, for example, seizures, migraines, or considerable liver harm, states Dr Dimple Jangda, an Ayurveda and Stomach Wellbeing mentor.

      The flood in the fame of consuming crude leafy foods can be ascribed to the apparent medical advantages got from their normal supplements and compounds. Nonetheless, it is fundamental to recognize the potential well-being dangers related to the utilization of uncooked food sources. Albeit crude produce flaunts a few dietary benefits, it is basic to stay perceptive of the dangers they could posture to our prosperity.

      Dr Dimple Jangda, an Ayurveda and Stomach Wellbeing mentor discussed four such crude leafy foods that ought not be devoured by any stretch of the imagination without washing and cooking them appropriately.

      1. Colacia leaves

      Otherwise called arbi ka patta ought to be whitened in serious trouble prior to remembering for your eating regimen. Eating crude colocasia passes on can be dangerous for your wellbeing because of the presence of normally happening substances that could be risky while perhaps not enough handled. The main pressing concern with consuming crude colocasia leaves is the presence of oxalates and calcium oxalate precious stones. These gems can possibly aggravate the linings of the mouth and throat, bringing about sensations like tingling, consuming, and, surprisingly, expected expanding.

      2) Kale and spinach

      They ought to be whitened in major trouble since they have high oxalate levels, which are diminished during the cycle. Consuming crude products of the soil, including kale and spinach, accompanies the potential for microbial tainting. This could include destructive microscopic organisms like E. coli or Salmonella. While washing these greens can bring down the gamble, it’s essential to recognize that the opportunity of tainting is as yet present.

      3) Cabbage

      This is notable for containing tapeworms and their subtle eggs, which are tapeworms. Your vegetable washes are excessively delicate for a portion of these tapeworms since they have to endure probably the most intense insect sprays and herbicides. Prior to eating, whiten your cabbage in steaming hot water and completely cook it.

      4) Capsicum

      Since tapeworm eggs can live inside the natural product, it is essential to make sure to eliminate the crown, deseed, and wash the capsicum in steaming hot water. Like different other crude leafy foods, there exists a minor chance of microbial defilement on the outer layer of crude capsicum, which could include microscopic organisms like E. coli or Salmonella. Completely washing the capsicum prior to eating is an action that can help with lessening this likely gamble.

      5) Aubergine

      Crude aubergine, otherwise called eggplant, incorporates solanine, a normally happening harmful substance present in nightshade vegetables like tomatoes and potatoes. In critical amounts, solanine can prompt queasiness, heaving, and stomach-related inconveniences. The most common way of cooking the auberges separates solanine, delivering it protected to eat.

      Yet again tapeworm eggs are tracked down in the seeds. To forestall parasites, tapeworms, and tapeworm eggs from entering our circulatory system, make certain to completely warm food. Moreover, the possibility exists for microbial pollution, including microscopic organisms and microorganisms, to be available on the external layer of crude aubergine. Yet again tapeworm eggs are tracked down in the seeds. To forestall parasites, tapeworms, and tapeworm eggs from entering our circulation system, make certain to

      Tags: , ,

      ViewState

      7 Apr

      Understanding ASP.NET View State

      Introduction

      Microsoft® ASP.NET view state, in a nutshell, is the technique used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks. In my experiences as a trainer and consultant, view state has caused the most confusion among ASP.NET developers. When creating custom server controls or doing more advanced page techniques, not having a solid grasp of what view state is and how it works can come back to bite you. Web designers who are focused on creating low-bandwidth, streamlined pages oftentimes find themselves frustrated with view state, as well. The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE. This hidden form field can easily get very large, on the order of tens of kilobytes. Not only does the __VIEWSTATE form field cause slower downloads, but, whenever the user posts back the Web page, the contents of this hidden form field must be posted back in the HTTP request, thereby lengthening the request time, as well.

      This article aims to be an in-depth examination of the ASP.NET view state. We’ll look at exactly what view state is storing, and how the view state is serialized to the hidden form field and deserialized back on postback. We’ll also discuss techniques for reducing the bandwidth required by the view state.

      Note   This article is geared toward the ASP.NET page developer rather than the ASP.NET server control developer. This article therefore does not include a discussion on how a control developer would implement saving state. For an in-depth discussion on that issue, refer to the book Developing Microsoft ASP.NET Server Controls and Components.

      Before we can dive into our examination of view state, it is important that we first take a quick moment to discuss the ASP.NET page life cycle. That is, what exactly happens when a request comes in from a browser for an ASP.NET Web page? We’ll step through this process in the next section.

      The ASP.NET Page Life Cycle

      Each time a request arrives at a Web server for an ASP.NET Web page, the first thing the Web server does is hand off the request to the ASP.NET engine. The ASP.NET engine then takes the request through a pipeline composed of numerous stages, which includes verifying file access rights for the ASP.NET Web page, resurrecting the user’s session state, and so on. At the end of the pipeline, a class corresponding to the requested ASP.NET Web page is instantiated and the ProcessRequest() method is invoked (see Figure 1).

      Figure 1. ASP.NET Page Handling

      This life cycle of the ASP.NET page starts with a call to the ProcessRequest() method. This method begins by initializing the page’s control hierarchy. Next, the page and its server controls proceed lock-step through various phases that are essential to executing an ASP.NET Web page. These steps include managing view state, handling postback events, and rendering the page’s HTML markup. Figure 2 provides a graphical representation of the ASP.NET page life cycle. The life cycle ends by handing off the Web page’s HTML markup to the Web server, which sends it back to the client that requested the page.

      Note   A detailed discussion of the steps leading up to the ASP.NET page life cycle is beyond the scope of this article. For more information read Michele Leroux-Bustamante’s Inside IIS & ASP.NET. For a more detailed look at HTTP handlers, which are the endpoints of the ASP.NET pipeline, check out my previous article on HTTP Handlers.

      What is important to realize is that each and every time an ASP.NET Web page is requested it goes through these same life cycle stages (shown in Figure 2).

      Figure 2. Events in the Page Life Cycle

      Stage 0 – Instantiation

      The life cycle of the ASP.NET page begins with instantiation of the class that represents the requested ASP.NET Web page, but how is this class created? Where is it stored?

      ASP.NET Web pages, as you know, are made up of both an HTML portion and a code portion, with the HTML portion containing HTML markup and Web control syntax. The ASP.NET engine converts the HTML portion from its free-form text representation into a series of programmatically-created Web controls.

      When an ASP.NET Web page is visited for the first time after a change has been made to the HTML markup or Web control syntax in the .aspx page, the ASP.NET engine auto-generates a class. If you created your ASP.NET Web page using the code-behind technique, this autogenerated class is derived from the page’s associated code-behind class (note that the code-behind class must be derived itself, either directly or indirectly, from the System.Web.UI.Page class); if you created your page with an in-line, server-side <script> block, the class derives directly from System.Web.UI.Page. In either case, this autogenerated class, along with a compiled instance of the class, is stored in the WINDOWS\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder, in part so that it doesn’t need to be recreated for each page request.

      The purpose of this autogenerated class is to programmatically create the page’s control hierarchy. That is, the class is responsible for programmatically creating the Web controls specified in the page’s HTML portion. This is done by translating the Web control syntax—<asp:WebControlName Prop1=”Value1″ … />—into the class’s programming language (C# or Microsoft® Visual Basic® .NET, most typically). In addition to the Web control syntax being converted into the appropriate code, the HTML markup present in the ASP.NET Web page’s HTML portion is translated to Literal controls.

      All ASP.NET server controls can have a parent control, along with a variable number of child controls. The System.Web.UI.Page class is derived from the base control class (System.Web.UI.Control), and therefore also can have a set of child controls. The top-level controls declared in an ASP.NET Web page’s HTML portion are the direct children of the autogenerated Page class. Web controls can also be nested inside one another. For example, most ASP.NET Web pages contain a single server-side Web Form, with multiple Web controls inside the Web Form. The Web Form is an HTML control (System.Web.UI.HtmlControls.HtmlForm). Those Web controls inside the Web Form are children of the Web Form.

      Since server controls can have children, and each of their children may have children, and so on, a control and its descendents form a tree of controls. This tree of controls is called the control hierarchy. The root of the control hierarchy for an ASP.NET Web page is the Page-derived class that is autogenerated by the ASP.NET engine.

      Whew! Those last few paragraphs may have been a bit confusing, as this is not the easiest subject to discuss or digest. To clear out any potential confusion, let’s look at a quick example. Imagine you have an ASP.NET Web page with the following HTML portion:

      <html>

      <body>

        <h1>Welcome to my Homepage!</h1>

        <form runat=”server”>

          What is your name?

          <asp:TextBox runat=”server” ID=”txtName”></asp:TextBox>

          <br />What is your gender?

          <asp:DropDownList runat=”server” ID=”ddlGender”>

            <asp:ListItem Select=”True” Value=”M”>Male</asp:ListItem>

            <asp:ListItem Value=”F”>Female</asp:ListItem>

            <asp:ListItem Value=”U”>Undecided</asp:ListItem>

          </asp:DropDownList>

          <br />

          <asp:Button runat=”server” Text=”Submit!”></asp:Button>

        </form>

      </body>

      </html>

      When this page is first visited, a class will be autogenerated that contains code to programmatically build up the control hierarchy. The control hierarchy for this example can be seen in Figure 3.

      Figure 3. Control Hierarchy for sample page

      This control hierarchy is then converted to code that is similar to the following:

      Page.Controls.Add(

        new LiteralControl(@”<html>\r\n<body>\r\n

          <h1>Welcome to my Homepage!</h1>\r\n”));

      HtmlForm Form1 = new HtmlForm();

      Form1.ID = “Form1”;

      Form1.Method = “post”;

      Form1.Controls.Add(

        new LiteralControl(“\r\nWhat is your name?\r\n”));

      TextBox TextBox1 = new TextBox();

      TextBox1.ID = “txtName”;

      Form1.Controls.Add(TextBox1);

      Form1.Controls.Add(

        new LiteralControl(“\r\n<br />What is your gender?\r\n”));

      DropDownList DropDownList1 = new DropDownList();

      DropDownList1.ID = “ddlGender”;

      ListItem ListItem1 = new ListItem();

      ListItem1.Selected = true;

      ListItem1.Value = “M”;

      ListItem1.Text = “Male”;

      DropDownList1.Items.Add(ListItem1);

      ListItem ListItem2 = new ListItem();

      ListItem2.Value = “F”;

      ListItem2.Text = “Female”;

      DropDownList1.Items.Add(ListItem2);

      ListItem ListItem3 = new ListItem();

      ListItem3.Value = “U”;

      ListItem3.Text = “Undecided”;

      DropDownList1.Items.Add(ListItem3);

      Form1.Controls.Add(

        new LiteralControl(“\r\n<br /> \r\n”));

      Button Button1 = new Button();

      Button1.Text = “Submit!”;

      Form1.Controls.Add(Button1);

      Form1.Controls.Add(

        new LiteralControl(“\r\n</body>\r\n</html>”));

      Controls.Add(Form1);

      Note   The C# source code above is not the precise code that is autogenerated by the ASP.NET engine. Rather, it’s a cleaner and easier to read version of the autogenerated code. To see the full autogenerated code—which won’t win any points for readability—navigate to the WINDOWS\Microsoft.NET\Framework\Version\Temporary ASP.NET Files folder and open one of the .cs or .vb files.

      One thing to notice is that, when the control hierarchy is constructed, the properties that are explicitly set in the declarative syntax of the Web control are assigned in the code. (For example, the Button Web control has its Text property set to “Submit!” in the declarative syntax – Text=”Submit!” – as well as in the autogenerated class—Button1.Text = “Submit!”;.

      Stage 1 – Initialization

      After the control hierarchy has been built, the Page, along with all of the controls in its control hierarchy, enter the initialization stage. This stage is marked by having the Page and controls fire their Init events. At this point in the page life cycle, the control hierarchy has been constructed, and the Web control properties that are specified in the declarative syntax have been assigned.

      We’ll look at the initialization stage in more detail later in this article. With regards to view state it is important for two reasons; first, server controls don’t begin tracking view state changes until right at the end of the initialization stage. Second, when adding dynamic controls that need to utilize view state, these controls will need to be added during the Page’s Init event as opposed to the Load event, as we’ll see shortly.

      Stage 2 – Load View State

      The load view state stage only happens when the page has been posted back. During this stage, the view state data that had been saved from the previous page visit is loaded and recursively populated into the control hierarchy of the Page. It is during this stage that the view state is validated. As we’ll discuss later in this article, the view state can become invalid due to a number of reasons, such as view state tampering, and injecting dynamic controls into the middle of the control hierarchy.

      Stage 3 – Load Postback Data

      The load postback data stage also only happens when the page has been posted back. A server control can indicate that it is interested in examining the posted back data by implementing the IPostBackDataHandler interface. In this stage in the page life cycle, the Page class enumerates the posted back form fields, and searches for the corresponding server control. If it finds the control, it checks to see if the control implements the IPostBackDataHandler interface. If it does, it hands off the appropriate postback data to the server control by calling the control’s LoadPostData() method. The server control would then update its state based on this postback data.

      To help clarify things, let’s look at a simple example. One nice thing about ASP.NET is that the Web controls in a Web Form remember their values across postback. That is, if you have a TextBox Web control on a page and the user enters some value into the TextBox and posts back the page, the TextBox’s Text property is automatically updated to the user’s entered value. This happens because the TextBox Web control implements the IPostBackDataHandler interface, and the Page class hands off the appropriate value to the TextBox class, which then updates its Text property.

      To concretize things, imagine that we have an ASP.NET Web page with a TextBox whose ID property is set to txtName. When the page is first visited, the following HTML will be rendered for the TextBox: <input type=”text” id=”txtName” name=”txtName” />. When the user enters a value into this TextBox (such as, “Hello, World!”) and submits the form, the browser will make a request to the same ASP.NET Web page, passing the form field values back in the HTTP POST headers. These include the hidden form field values (such as __VIEWSTATE), along with the value from the txtName TextBox.

      When the ASP.NET Web page is posted back in the load postback data stage, the Page class sees that one of the posted back form fields corresponds to the IPostBackDataHandler interface. There is such a control in the hierarchy, so the TextBox’s LoadPostData() method is invoked, passing in the value the user entered into the TextBox (“Hello, World!”). The TextBox’s LoadPostData() method simply assigns this passed in value to its Text property.

      Notice that in our discussion on the load postback data stage, there was no mention of view state. You might naturally be wondering, therefore, why I bothered to mention the load postback data stage in an article about view state. The reason is to note the absence of view state in this stage. It is a common misconception among developers that view state is somehow responsible for having TextBoxes, CheckBoxes, DropDownLists, and other Web controls remember their values across postback. This is not the case, as the values are identified via posted back form field values, and assigned in the LoadPostData() method for those controls that implement IPostBackDataHandler.

      Stage 4 – Load

      This is the stage with which all ASP.NET developers are familiar, as we’ve all created an event handler for a page’s Load event (Page_Load). When the Load event fires, the view state has been loaded (from stage 2, Load View State), along with the postback data (from stage 3, Load Postback Data). If the page has been posted back, when the Load event fires we know that the page has been restored to its state from the previous page visit.

      Stage 5 – Raise Postback Event

      Certain server controls raise events with respect to changes that occurred between postbacks. For example, the DropDownList Web control has a SelectedIndexChanged event, which fires if the DropDownList’s SelectedIndex has changed from the SelectedIndex value in the previous page load. Another example: if the Web Form was posted back due to a Button Web control being clicked, the Button’s Click event is fired during this stage.

      There are two flavors of postback events. The first is a changed event. This event fires when some piece of data is changed between postbacks. An example is the DropDownLists SelectedIndexChanged event, or the TextBox’s TextChanged event. Server controls that provide changed events must implement the IPostBackDataHandler interface. The other flavor of postback events is the raised event. These are events that are raised by the server control for whatever reason the control sees fit. For example, the Button Web control raises the Click event when it is clicked, and the Calendar control raises the VisibleMonthChanged event when the user moves to another month. Controls that fire raised events must implement the IPostBackEventHandler interface.

      Since this stage inspects postback data to determine if any events need to be raised, the stage only occurs when the page has been posted back. As with the load postback data stage, the raise postback event stage does not use view state information at all. Whether or not an event is raised depends on the data posted back in the form fields.

      Stage 6 – Save View State

      In the save view state stage, the Page class constructs the page’s view state, which represents the state that must persist across postbacks. The page accomplishes this by recursively calling the SaveViewState() method of the controls in its control hierarchy. This combined, saved state is then serialized into a base-64 encoded string. In stage 7, when the page’s Web Form is rendered, the view state is persisted in the page as a hidden form field.

      Stage 7 – Render

      In the render stage the HTML that is emitted to the client requesting the page is generated. The Page class accomplishes this by recursively invoking the RenderControl() method of each of the controls in its hierarchy.

      These seven stages are the most important stages with respect to understanding view state. (Note that I did omit a couple of stages, such as the PreRender and Unload stages.) As you continue through the article, keep in mind that every single time an ASP.NET Web page is requested, it proceeds through these series of stages.

      The Role of View State

      View state’s purpose in life is simple: it’s there to persist state across postbacks. (For an ASP.NET Web page, its state is the property values of the controls that make up its control hierarchy.) This begs the question, “What sort of state needs to be persisted?” To answer that question, let’s start by looking at what state doesn’t need to be persisted across postbacks. Recall that in the instantiation stage of the page life cycle, the control hierarchy is created and those properties that are specified in the declarative syntax are assigned. Since these declarative properties are automatically reassigned on each postback when the control hierarchy is constructed, there’s no need to store these property values in the view state.

      For example, imagine we have a Label Web control in the HTML portion with the following declarative syntax:

      <asp:Label runat=”server” Font-Name=”Verdana”

        Text=”Hello, World!”></asp:Label>

      When the control hierarchy is built in the instantiation stage, the Label’s Text property will be set to “Hello, World!” and its Font property will have its Name property set to Verdana. Since these properties will be set each and every page visit during the instantiation stage, there’s no need to persist this information in the view state.

      What needs to be stored in the view state is any programmatic changes to the page’s state. For example, suppose that in addition to this Label Web control, the page also contained two Button Web controls, a Change Message Button and an Empty Postback button. The Change Message Button has a Click event handler that assigns the Label’s Text property to “Goodbye, Everyone!”; the Empty Postback Button just causes a postback, but doesn’t execute any code. The change to the Label’s Text property in the Change Message Button would need to be saved in the view state. To see how and when this change would be made, let’s walk through a quick example. Assuming that the HTML portion of the page contains the following markup:

      <asp:Label runat=”server” ID=”lblMessage”

        Font-Name=”Verdana” Text=”Hello, World!”></asp:Label>

      <br />

      <asp:Button runat=”server”

        Text=”Change Message” ID=”btnSubmit”></asp:Button>

      <br />

      <asp:Button runat=”server” Text=”Empty Postback”></asp:Button>

      And the code-behind class contains the following event handler for the Button’s Click event:

      private void btnSubmit_Click(object sender, EventArgs e)

      {

        lblMessage.Text = “Goodbye, Everyone!”;

      }

      Figure 4 illustrates the sequence of events that transpire, highlighting why the change to the Label’s Text property needs to be stored in the view state.

      Figure 4. Events and View State

      To understand why saving the Label’s changed Text property in the view state is vital, consider what would happen if this information were not persisted in view state. That is, imagine that in step 2’s save view state stage, no view state information was persisted. If this were the case, then in step 3 the Label’s Text property would be assigned to “Hello, World!” in the instantiation stage, but would not be reassigned to “Goodbye, Everyone!” in the load view state stage. Therefore, from the end user’s perspective, the Label’s Text property would be “Goodbye, Everyone!” in step 2, but would seemingly be reset to its original value (“Hello, World!”) in step 3, after clicking the Empty Postback button.

      View State and Dynamically Added Controls

      Since all ASP.NET server controls contain a collection of child controls exposed through the Controls property, controls can be dynamically added to the control hierarchy by appending new controls to a server control’s Controls collection. A thorough discussion of dynamic controls is a bit beyond the scope of this article, so we won’t cover that topic in detail here; instead, we’ll focus on how to manage view state for controls that are added dynamically. (For a more detailed lesson on using dynamic controls, check out Dynamic Controls in ASP.NET and Working with Dynamically Created Controls.)

      Recall that in the page life cycle, the control hierarchy is created and the declarative properties are set in the instantiation stage. Later, in the load view state stage, the state that had been altered in the prior page visit is restored. Thinking a bit about this, three things become clear when working with dynamic controls:

      1. Since the view state only persists changed control state across postbacks, and not the actual controls themselves, dynamically added controls must be added to the ASP.NET Web page, on both the initial visit as well as all subsequent postbacks.
      2. Dynamic controls are added to the control hierarchy in the code-behind class, and therefore are added at some point after the instantiation stage.
      3. The view state for these dynamically added controls is automatically saved in the save view state stage. (What happens on postback if the dynamic controls have not yet been added by the time the load view state stage rolls, however?)

      So, dynamically added controls must be programmatically added to the Web page on each and every page visit. The best time to add these controls is during the initialization stage of the page life cycle, which occurs before the load view state stage. That is, we want to have the control hierarchy complete before the load view state stage arrives. For this reason, it is best to create an event handler for the Page class’s Init event in your code-behind class, and add your dynamic controls there.

      Note   You may be able to get away with loading your controls in the Page_Load event handler and maintaining the view state properly. It all depends on whether or not you are setting any properties of the dynamically loaded controls programmatically and, if so, when you’re doing it relative to the Controls.Add(dynamicControl) line. A thorough discussion of this is a bit beyond the scope of this article, but the reason it may work is because the Controls property’s Add() method recursively loads the parent’s view state into its children, even though the load view state stage has passed.

      When adding a dynamic control c to some parent control p based on some condition (that is, when not loading them on each and every page visit), you need to make sure that you add c to the end of p‘s Controls collection. The reason is because the view state for p contains the view state for p‘s children as well, and, as we’ll discuss in the “Parsing the View State” section, p‘s view state specifies the view state for its children by index. (Figure 5 illustrates how inserting a dynamic control somewhere other than the end of the Controls collection can cause a corrupted view state.)

      Figure 5. Effect of inserting controls on View State

      The ViewState Property

      Each control is responsible for storing its own state, which is accomplished by adding its changed state to its ViewState property. The ViewState property is defined in the System.Web.UI.Control class, meaning that all ASP.NET server controls have this property available. (When talking about view state in general I’ll use lower case letters with a space between view and state; when discussing the ViewState property, I’ll use the correct casing and code-formatted text.)

      If you examine the simple properties of any ASP.NET server control you’ll see that the properties read and write directly to the view state. (You can view the decompiled source code for a .NET assembly by using a tool like Reflector.) For example, consider the HyperLink Web control’s NavigateUrl property. The code for this property looks like so:

      public string NavigateUrl

      {

        get

        {

          string text = (string) ViewState[“NavigateUrl”];

          if (text != null)

             return text;

          else

             return string.Empty;

        }

        set

        {

          ViewState[“NavigateUrl”] = value;

        }

      }

      As this code sample illustrates, whenever a control’s property is read, the control’s ViewState is consulted. If there is not an entry in the ViewState, then the default value for the property is returned. When the property is assigned, the assigned value is written directly to the ViewState.

      Note   All Web controls use the above pattern for simple properties. Simple properties are those that are scalar values, like strings, integers, Booleans, and so on. Complex properties, such as the Label’s Font property, which might be classes themselves, use a different approach. Consult the book Developing Microsoft ASP.NET Server Controls and Components for more information on state maintenance techniques for ASP.NET server controls.

      The ViewState property is of type System.Web.UI.StateBag. The StateBag class provides a means to store name and value pairs, using a System.Collections.Specialized.HybridDictionary behind the scenes. As the NavigateUrl property syntax illustrates, items can be added to and queried from the StateBag using the same syntax you could use to access items from a Hashtable.

      Timing the Tracking of View State

      Recall that earlier I said the view state only stores state that needs to be persisted across postbacks. One bit of state that does not need to be persisted across postbacks is the control’s properties specified in the declarative syntax, since they are automatically reinstated in the page’s instantiation stage. For example, if we have a HyperLink Web control on an ASP.NET Web page and declaratively set the NavigateUrl property to http://www.scottonwriting.net/ then this information doesn’t need to be stored in the view state.

      Seeing the HyperLink control’s NavigateUrl property’s code, however, it looks as if the control’s ViewState is written to whenever the property value is set. In the instantiation stage, therefore, where we’d have something like HyperLink1.NavigateUrl = http://www.ScottOnWriting.NET;, it would only make sense that this information would be stored in the view state.

      Regardless of what might seem apparent, this is not the case. The reason is because the StateBag class only tracks changes to its members after its TrackViewState() method has been invoked. That is, if you have a StateBag, any and all additions or modifications that are made before TrackViewState() is made will not be saved when the SaveViewState() method is invoked. The TrackViewState() method is called at the end of the initialization stage, which happens after the instantiation stage. Therefore, the initial property assignments in the instantiation stage—while written to the ViewState in the properties’ set accessors—are not persisted during the SaveViewState() method call in the save view state stage, because the TrackViewState() method has yet to be invoked.

      Note   The reason the StateBag has the TrackViewState() method is to keep the view state as trimmed down as possible. Again, we don’t want to store the initial property values in the view state, as they don’t need to be persisted across postbacks. Therefore, the TrackViewState() method allows the state management to begin after the instantiation and initialization stages.

      Storing Information in the Page’s ViewState Property

      Since the Page class is derived from the System.Web.UI.Control class, it too has a ViewState property. In fact, you can use this property to persist page-specific and user-specific information across postbacks. From an ASP.NET Web page’s code-behind class, the syntax to use is simply:

      ViewState[keyName] = value

      There are a number of scenarios when being able to store information in the Page’s ViewState is useful. The canonical example is in creating a pageable, sortable DataGrid (or a sortable, editable DataGrid), since the sort expression must be persisted across postbacks. That is, if the DataGrid’s data is first sorted, and then paged, when binding the next page of data to the DataGrid it is important that you get the next page of the data when it is sorted by the user’s specified sort expression. The sort expression therefore needs to be persisted in some manner. There are assorted techniques, but the simplest, in my opinion, is to store the sort expression in the Page’s ViewState.

      For more information on creating sortable, pageable DataGrids (or a pageable, sortable, editable DataGrid), pick up a copy of my book ASP.NET Data Web Controls Kick Start.

      The Cost of View State

      Nothing comes for free, and view state is no exception. The ASP.NET view state imposes two performance hits whenever an ASP.NET Web page is requested:

      1. On all page visits, during the save view state stage the Page class gathers the collective view state for all of the controls in its control hierarchy and serializes the state to a base-64 encoded string. (This is the string that is emitted in the hidden __VIEWSTATE form filed.) Similarly, on postbacks, the load view state stage needs to deserialize the persisted view state data, and update the pertinent controls in the control hierarchy.
      2. The __VIEWSTATE hidden form field adds extra size to the Web page that the client must download. For some view state-heavy pages, this can be tens of kilobytes of data, which can require several extra seconds (or minutes!) for modem users to download. Also, when posting back, the __VIEWSTATE form field must be sent back to the Web server in the HTTP POST headers, thereby increasing the postback request time.

      If you are designing a Web site that is commonly accessed by users coming over a modem connection, you should be particularly concerned with the bloat the view state might add to a page. Fortunately, there are a number of techniques that can be employed to reduce view state size. We’ll first see how to selectively indicate whether or not a server control should save its view state. If a control’s state does not need to be persisted across postbacks, we can turn off view state tracking for that control, thereby saving the extra bytes that would otherwise have been added by that control. Following that, we’ll examine how to remove the view state from the page’s hidden form fields altogether, storing the view state instead on the Web server’s file system.

      Disabling the View State

      In the save view state stage of the ASP.NET page life cycle, the Page class recursively iterates through the controls in its control hierarchy, invoking each control’s SaveViewState() method. This collective state is what is persisted to the hidden __VIEWSTATE form field. By default, all controls in the control hierarchy will record their view state when their SaveViewState() method is invoked. As a page developer, however, you can specify that a control should not save its view state or the view state of its children controls by setting the control’s EnableViewState property to False (the default is True).

      The EnableViewState property is defined in the System.Web.UI.Control class, so all server controls have this property, including the Page class. You can therefore indicate that an entire page’s view state need not be saved by setting the Page class’s EnableViewState to False. (This can be done either in the code-behind class with Page.EnableViewState = false; or as a @Page-level directive—<%@Page EnableViewState=”False” %>.)

      Not all Web controls record the same amount of information in their view state. The Label Web control, for example, records only programmatic changes to its properties, which won’t greatly impact the size of the view state. The DataGrid, however, stores all of its contents in the view state. For a DataGrid with many columns and rows, the view state size can quickly add up! For example, the DataGrid shown in Figure 6 (and included in this article’s code download as HeavyDataGrid.aspx) has a view state size of roughly 2.8 kilobytes, and a total page size of 5,791 bytes. (Almost half of the page’s size is due to the __VIEWSTATE hidden form field!) Figure 7 shows a screenshot of the view state, which can be seen by visiting the ASP.NET Web page, doing a View\Source, and then locating the __VIEWSTATE hidden form field.

      Figure 6. DataGrid control

      Figure 7. View State for DataGrid control

      The download for this article also includes an ASP.NET Web page called LightDataGrid.aspx, which has the same DataGrid as shown in Figure 6, but with the EnableViewState property set to False. The total view state size for this page? 96 bytes. The entire page size clocks in a 3,014 bytes. LightDataGrid.aspx boasts a view state size about 1/30th the size of HeavyDataGrid.aspx, and a total download size that’s about half of HeavyDataGrid.aspx. With wider DataGrids with more rows, this difference would be even more pronounced. (For more information on performance comparisons between view state-enabled DataGrids and view state-disabled DataGrids, refer to Deciding When to Use the DataGrid, DataList, or Repeater.)

      Hopefully the last paragraph convinces you of the benefit of intelligently setting the EnableViewState property to False, especially for “heavy” view state controls like the DataGrid. The question now, is, “When can I safely set the EnableViewState property to False?” To answer that question, consider when you need to use the view state—only when you need to remember state across postbacks. The DataGrid stores its contents in the view state so the page developer doesn’t need to rebind the database data to the DataGrid on each and every page load, but only on the first one. The benefit is that the database doesn’t need to be accessed as often. If, however, you set a DataGrid’s EnableViewState property to False, you’ll need to rebind the database data to the DataGrid on both the first page load and every subsequent postback.

      For a Web page that has a read-only DataGrid, like the one in Figure 6, you’d definitely want to set the DataGrid’s EnableViewState property to False. You can even create sortable and pageable DataGrids with the view state disabled (as can be witnessed in the LightDataGrid-WithFeatures.aspx page, included in the download), but, again, you’ll need to be certain to bind the database data to the DataGrid on the first page visit, as well as on all subsequent postbacks.

      Note   Creating an editable DataGrid with disabled view state requires some intricate programming, which involves parsing of the posted back form fields in the editable DataGrid. Such strenuous effort is required because, with an editable DataGrid blindly rebinding, the database data to the DataGrid will overwrite any changes the user made (see this FAQ for more information).

      Specifying Where to Persist the View State

      After the page has collected the view state information for all of the controls in its control hierarchy in the save view state stage, it persists it to the __VIEWSTATE hidden form field. This hidden form field can, of course, greatly add to the overall size of the Web page. The view state is serialized to the hidden form field in the Page class’s SavePageStateToPersistenceMedium() method during the save view state stage, and is deserialized by the Page class’s LoadPageStateFromPersistenceMedium() method in the load view state stage. With just a bit of work we can have the view state persisted to the Web server’s file system, rather than as a hidden form field weighing down the page. To accomplish this we’ll need to create a class that derives from the Page class and overrides the SavePageStateToPersistenceMedium() and LoadPageStateFromPersistenceMedium() methods.

      Note   There is a third-party product called Flesk.ViewStateOptimizer that reduces the view state bloat using a similar technique.

      The view state is serialized and deserialized by the System.Web.UI.LosFormatter class—the LOS stands for limited object serialization—and is designed to efficiently serialize certain types of objects into a base-64 encoded string. The LosFormatter can serialize any type of object that can be serialized by the BinaryFormatter class, but is built to efficiently serialize objects of the following types:

      • Strings
      • Integers
      • Booleans
      • Arrays
      • ArrayLists
      • Hashtables
      • Pairs
      • Triplets

      Note   The Pair and Triplet are two classes found in the System.Web.UI namespace, and provide a single class to store either two or three objects. The Pair class has properties First and Second to access its two elements, while Triplet has First, Second, and Third as properties.

      The SavePageStateToPersistenceMedium() method is called from the Page class and passed in the combined view state of the page’s control hierarchy. When overriding this method, we need to use the LosFormatter() to serialize the view state to a base-64 encoded string, and then store this string in a file on the Web server’s file system. There are two main challenges with this approach:

      1. Coming up with an acceptable file naming scheme. Since the view state for a page will likely vary based on the user’s interactions with the page, the stored view state must be unique for each user and for each page.
      2. Removing the view state files from the file system when they are no longer needed.

      To tackle the first challenge, we’ll name the persisted view state file based on the user’s SessionID and the page’s URL. This approach will work beautifully for all users whose browsers accept session-level cookies. Those who do not accept cookies, however, will have a unique session ID generated for them on each page visit, thereby making this naming technique unworkable for them. For this article I’m just going to demonstrate using the SessionID / URL file name scheme, although it won’t work for those whose browsers are configured not to accept cookies. Also, it won’t work for a Web farm unless all servers store the view state files to a centralized location.

      Note   One workaround would be to use a globally unique identifier (GUID) as the file name for the persisted view state, saving this GUID in a hidden form field on the ASP.NET Web page. This approach, unfortunately, would take quite a bit more effort than using the SessionID / URL scheme, since it involves injecting a hidden form field into the Web Form. For that reason, I’ll stick to illustrating the simpler approach for this article.

      The second challenge arises because, each time a user visits a different page, a new file holding that page’s view state will be created. Over time this will lead to thousands of files. Some sort of automated task would be needed to periodically clean out the view state files older than a certain date. I leave this as an exercise for the reader.

      To persist view state information to a file, we start by creating a class that derives from the Page class. This derived class, then, needs to override the SavePageStateToPersistenceMedium() and LoadPageStateFromPersistenceMedium() methods. The following code presents such a class:

      public class PersistViewStateToFileSystem : Page

      {

         protected override void

           SavePageStateToPersistenceMedium(object viewState)

         {

            // serialize the view state into a base-64 encoded string

            LosFormatter los = new LosFormatter();

            StringWriter writer = new StringWriter();

            los.Serialize(writer, viewState);

            // save the string to disk

            StreamWriter sw = File.CreateText(ViewStateFilePath);

            sw.Write(writer.ToString());

            sw.Close();

         }

         protected override object LoadPageStateFromPersistenceMedium()

         {

            // determine the file to access

            if (!File.Exists(ViewStateFilePath))

               return null;

            else

            {

               // open the file

               StreamReader sr = File.OpenText(ViewStateFilePath);

               string viewStateString = sr.ReadToEnd();

               sr.Close();

               // deserialize the string

               LosFormatter los = new LosFormatter();

               return los.Deserialize(viewStateString);

            }

         }

         public string ViewStateFilePath

         {

            get

            {

               string folderName =

                 Path.Combine(Request.PhysicalApplicationPath,

                 “PersistedViewState”);

               string fileName = Session.SessionID + “-” +

                 Path.GetFileNameWithoutExtension(Request.Path).Replace(“/”,

                 “-“) + “.vs”;

               return Path.Combine(folderName, fileName);

            }

         }

      }

      The class contains a public property ViewStateFilePath, which returns the physical path to the file where the particular view state information will be stored. This file path is dependent upon the user’s SessionID and the URL of the requested page.

      Notice that the SavePageStateToPersistenceMedium() method accepts an object input parameter. This object is the view state object that is built up from the save view state stage. The job of SavePageStateToPersistenceMedium() is to serialize this object and persist it in some manner. The method’s code simply creates an instance of the LosFormatter object and invokes its Serialize() method, serializing the passed-in view state information to the StringWriter writer. Following that, the specified file is created (or overwritten, if it already exists) with the contents of the base-64 encoded, serialized view state string.

      The LoadPageStateFromPersistenceMedium() method is called at the beginning of the load view state stage. Its job is to retrieve the persisted view state and deserialize back into an object that can be propagated into the page’s control hierarchy. This is accomplished by opening the same file where the persisted view state was stored on the last visit, and returning the deserialized version via the Deserialize() method in LosFormatter().

      Again, this approach won’t work with users that do not accept cookies, but for those that do, the view state is persisted entirely on the Web server’s file system, thereby adding 0 bytes to the overall page size!

      Note   Another approach to reducing the bloat imposed by view state is to compress the serialized view state stream in the SavePageStateToPersistenceMedium() method, and then decompress it back to its original form in the LoadPageStateFromPersistenceMedium() method. Scott Galloway has a blog entry where he discusses his experiences with using #ziplib library to compress the view state.

      Parsing the View State

      When a page is rendered, it serializes its view state into a base-64 encoded string using the LosFormatter class and (by default) stores it in a hidden form field. On postback, the hidden form field is retrieved and deserialized back into the view state’s object representation, which is then used to restore the state of the controls in the control hierarchy. One detail we have overlooked up to this point in the article is what, exactly, is the structure of the Page class’s view state object?

      As we discussed earlier, entire view state of the Page is the sum of the view state of the controls in its control hierarchy. Put another way, at any point in the control hierarchy, the view state of that control represents the view state of that control along with the view state of all of its children controls. Since the Page class forms the root of the control hierarchy, its view state represents the view state for the entire control hierarchy.

      The Page class contains a SavePageViewState(), which is invoked during the page life cycle’s save view state stage. The SavePageViewState() method starts by creating a Triplet that contains the following three items:

      1. The page’s hash code. This hash code is used to ensure that the view state hasn’t been tampered with between postbacks. We’ll talk more about view state hashing in the “View State and Security Implications” section.
      2. The collective view state of the Page’s control hierarchy.
      3. An ArrayList of controls in the control hierarchy that need to be explicitly invoked by the page class during the raise postback event stage of the life cycle.

      The First and Third items in the Triplet are relatively straightforward; the Second item is where the view state for the Page’s control hierarchy is maintained. The Second item is generated by the Page by calling the SaveViewStateRecursive() method, which is defined in the System.Web.UI.Control class. SaveViewStateRecursive() saves the view state of the control and its descendents by returning a Triplet with the following information:

      1. The state present in the Control’s ViewState StageBag.
      2. An ArrayList of integers. This ArrayList maintains the indexes of the Control’s child controls that have a non-null view state.
      3. An ArrayList of the view states for the children controls. The ith view state in this ArrayList maps to the child control index in the ith item in the ArrayList in the Triplet’s Second item.

      The Control class computes the view state, returning a Triplet. The Second item of the Triplet contains the view state of the Control’s descendents. The end result is that the view state is comprised of many ArrayLists inside of Triplets inside of Triplets, inside of Triplets, inside of… (The precise contents in the view state depend on the controls in the hierarchy. More complex controls might serialize their own state to the view state using Pairs or object arrays. As we’ll see shortly, though, the view state is composed of a number of Triplets and ArrayLists nested as deep as the control hierarchy.)

      Programmatically Stepping Through the View State

      With just a little bit of work we can create a class that can parse through the view state and display its contents. The download for this article includes a class called ViewStateParser that provides such functionality. This class contains a ParseViewState() method that recursively steps through the view state. It takes in three inputs:

      1. The current view state object.
      2. How many levels deep we are in the view state recursion.
      3. A text label to display.

      The last two input parameters are just for display purposes. The code of this method, shown below, determines the type of the current view state object and displays the contents of the view state accordingly, by recursively calling itself on each of the current object’s members. (The variable tw is a TextWriter instance to which the output is being written.)

      protected virtual void ParseViewStateGraph(

        object node, int depth, string label)

      {

         tw.Write(System.Environment.NewLine);

         if (node == null)

         {

            tw.Write(String.Concat(Indent(depth), label, “NODE IS NULL”));

         }

         else if (node is Triplet)

         {

            tw.Write(String.Concat(Indent(depth), label, “TRIPLET”));

            ParseViewStateGraph(

              ((Triplet) node).First, depth+1, “First: “);

            ParseViewStateGraph(

              ((Triplet) node).Second, depth+1, “Second: “);

            ParseViewStateGraph(

              ((Triplet) node).Third, depth+1, “Third: “);

         }

         else if (node is Pair)

         {

            tw.Write(String.Concat(Indent(depth), label, “PAIR”));

            ParseViewStateGraph(((Pair) node).First, depth+1, “First: “);

            ParseViewStateGraph(((Pair) node).Second, depth+1, “Second: “);

         }

         else if (node is ArrayList)

         {

            tw.Write(String.Concat(Indent(depth), label, “ARRAYLIST”));

            // display array values

            for (int i = 0; i < ((ArrayList) node).Count; i++)

               ParseViewStateGraph(

                 ((ArrayList) node)[i], depth+1, String.Format(“({0}) “, i));

         }

         else if (node.GetType().IsArray)

         {

            tw.Write(String.Concat(Indent(depth), label, “ARRAY “));

            tw.Write(String.Concat(“(“, node.GetType().ToString(), “)”));

      IEnumerator e = ((Array) node).GetEnumerator();

            int count = 0;

            while (e.MoveNext())

               ParseViewStateGraph(

                 e.Current, depth+1, String.Format(“({0}) “, count++));

         }

         else if (node.GetType().IsPrimitive || node is string)

         {

            tw.Write(String.Concat(Indent(depth), label));

            tw.Write(node.ToString() + ” (” +

              node.GetType().ToString() + “)”);

         }

         else

         {

            tw.Write(String.Concat(Indent(depth), label, “OTHER – “));

            tw.Write(node.GetType().ToString());

         }

      }

      As the code shows, the ParseViewState() method iterates through the expected types—Triplet, Pair, ArrayList, arrays, and primitive types. For scalar values—integers, strings, etc.—the type and value are displayed; for aggregate types—arrays, Pairs, Triplets, etc.—the members that compose the type are displayed by recursively invoking ParseViewState().

      The ViewStateParser class can be utilized from an ASP.NET Web page (see the ParseViewState.aspx demo), or can be accessed directly from the SavePageStateToPersistenceMedium() method in a class that is derived from the Page class (see the ShowViewState class). Figures 8 and9 show the ParseViewState.aspx demo in action. As Figure 8 shows, the user is presented with a multi-line textbox into which they can paste the hidden __VIEWSTATE form field from some Web page. Figure 9 shows a snippet of the parsed view state for a page displaying file system information in a DataGrid.

      Figure 8. Decoding ViewState

      Figure 9. ViewState decoded

      In addition to the view state parser provided in this article’s download, Paul Wilson provides a view state parser on his Web site. Fritz Onion also has a view state decoder WinForms application available for download from the Resources section on his Web site.

      View State and Security Implications

      The view state for an ASP.NET Web page is stored, by default, as a base-64 encoded string. As we saw in the previous section, this string can easily be decoded and parsed, displaying the contents of the view state for all to see. This raises two security-related concerns:

      1. Since the view state can be parsed, what’s to stop someone from changing the values, re-serializing it, and using the modified view state?
      2. Since the view state can be parsed, does that mean I can’t place any sensitive information in the view state (such as passwords, connection strings, etc.)?

      Fortunately, the LosFormatter class has capabilities to address both of these concerns, as we’ll see over the next two sections. Before we delve into the solutions for these concerns, it is important to first note that view state should only be used to store non-sensitive data. View state does not house code, and should definitely not be used to place sensitive information like connection strings or passwords.

      Protecting the View State from Modification

      Even though view state should only store the state of the Web controls on the page and other non-sensitive data, nefarious users could cause you headaches if they could successfully modify the view state for a page. For example, imagine that you ran an eCommerce Web site that used a DataGrid to display a list of products for sale along with their cost. Unless you set the DataGrid’s EnableViewState property to False, the DataGrid’s contents—the names and prices of your merchandise—will be persisted in the view state.

      Nefarious users could parse the view state, modify the prices so they all read $0.01, and then deserialize the view state back to a base-64 encoded string. They could then send out e-mail messages or post links that, when clicked, submitted a form that sent the user to your product listing page, passing along the altered view state in the HTTP POST headers. Your page would read the view state and display the DataGrid data based on this view state. The end result? You’d have a lot of customers thinking they were going to be able to buy your products for only a penny!

      A simple means to protect against this sort of tampering is to use a machine authentication check, or MAC. Machine authentication checks are designed to ensure that the data received by a computer is the same data that it transmitted out—namely, that it hasn’t been tampered with. This is precisely what we want to do with the view state. With ASP.NET view state, the LosFormatter performs a MAC by hashing the view state data being serialized, and appending this hash to the end of the view state. (A hash is a quickly computed digest that is commonly used in symmetric security scenarios to ensure message integrity.) When the Web page is posted back, the LosFormatter checks to ensure that the appended hash matches up with the hashed value of the deserialized view state. If it does not match up, the view state has been changed en route.

      By default, the LosFormatter class applies the MAC. You can, however, customize whether or not the MAC occurs by setting the Page class’s EnableViewStateMac property. The default, True, indicates that the MAC should take place; a value of False indicates that it should not. You can further customize the MAC by specifying what hashing algorithm should be employed. In the machine.config file, search for the <machineKey> element’s validation attribute. The default hashing algorithm used is SHA1, but you can change it to MD5 if you like.

      Note   When using Server.Transfer() you may find you receive a problem with view state authentication. A number of articles online have mentioned that the only workaround is to set EnableViewStateMac to False. While this will certainly solve the problem, it opens up a security hole.

      Encrypting the View State

      Ideally the view state should not need to be encrypted, as it should never contain sensitive information. If needed, however, the LosFormatter does provide limited encryption support. The LosFormatter only allows for a single type of encryption: Triple DES. To indicate that the view state should be encrypted, set the <machineKey> element’s validation attribute in the machine.config file to 3DES.

      In addition to the validation attribute, the <machineKey> element contains validationKey and decryptionKey attributes, as well. The validationKey attribute specifies the key used for the MAC; decryptionKey indicates the key used in the Triple DES encryption. By default, these attributes are set to the value “AutoGenerate,IsolateApp,” which uniquely autogenerates the keys for each Web application on the server. This setting works well for a single Web server environment, but if you have a Web farm, it’s vital that all Web servers use the same keys for MAC and/or encryption and decryption. In this case you’ll need to manually enter a shared key among the servers in the Web farm. For more information on this process, and the <machineKey> element in general, refer to the <machineKey> technical documentation and Susan Warren’s article Taking a Bite Out of ASP.NET ViewState.

      The ViewStateUserKey Property

      Microsoft® ASP.NET version 1.1 added an additional Page class property—ViewStateUserKey. This property, if used, must be assigned a string value in the initialization stage of the page life cycle (in the Page_Init event handler). The point of the property is to assign some user-specific key to the view state, such as a username. The ViewStateUserKey, if provided, is used as a salt to the hash during the MAC.

      What the ViewStateUserKey property protects against is the case where a nefarious user visits a page, gathers the view state, and then entices a user to visit the same page, passing in their view state (see Figure 10). For more information on this property and its application, refer to Building Secure ASP.NET Pages and Controls.

      Figure 10. Protecting against attacks using ViewStateUserKey

      Conclusion

      In this article we examined the ASP.NET view state, studying not only its purpose, but also its functionality. To best understand how view state works, it is important to have a firm grasp on the ASP.NET page life cycle, which includes stages for loading and saving the view state. In our discussions on the page life cycle, we saw that certain stages—such as loading postback data and raising postback events—were not in any way related to view state.

      While view state enables state to be effortlessly persisted across postbacks, it comes at a cost, and that cost is page bloat. Since the view state data is persisted to a hidden form field, view state can easily add tens of kilobytes of data to a Web page, thereby increasing both the download and upload times for Web pages. To cut back on the page weight imposed by view state, you can selectively instruct various Web controls not to record their view state by setting the EnableViewState property to False. In fact, view state can be turned off for an entire page by setting the EnableViewState property to false in the @Page directive. In addition to turning off view state at the page-level or control-level, you can also specify an alternate backing store for view state, such as the Web server’s file system.

      This article wrapped up with a look at security concerns with view state. By default, the view state performs a MAC to ensure that the view state hasn’t been tampered with between postbacks. ASP.NET 1.1 provides the ViewStateUserKey property to add an additional level of security. The view state’s data can be encrypted using the Triple DES encryption algorithm, as well.

      Happy Programming!

      Tags:

      Best practices in developing asp.net applications – Part 1

      7 Apr

      Best practices in developing asp.net applications – Part 1

      1. Remove unused private fields and functions.

      2. Do not cast unnecessarily. Avoid duplicate casts where possible, since there is a cost associated with them.

      3. Properties that return arrays are prone to code inefficiencies. Consider using a collection or making this a method.

      4. To test for empty strings, check if String.Length is equal to zero. Constructs such as “”.Equals(someString) and String.Empty.Equals(someString) are less efficient than testing the string length. Replace these with checks for someString.Length == 0.

      5. Methods in the same type that differ only by return type can be difficult for developers

       

      and tools to properly recognize. When extending a type, be sure not to define new methods that differ from base type methods only by type.

      6. Use stringbuilder instead of string types for string manipulation.

      7. Use String.Format instead of concatenating and appending strings.

      8. Use Type.TryParse rather than Convert.ToDestinationType(). For example use int.TryParse() rather than Convert.ToInt32() which might throw an exception.

      9. Override Equals() method wherever applicable in your classes.

      10. Consider passing base types as parameters – Using base types as parameters to methods improves re-use of these methods if you only use methods & properties from the parameter’s base class. E.g. use Stream instead of FileStream as a parameter when only calling Stream.Read(), this makes the method work on all kind of streams instead of just File streams.

       

      1. Do not catch general exception types – You should not catch Exception or SystemException. Catching generic exception types can hide run-time problems from the library user, and can complicate debugging. You should catch only those exceptions that you can handle gracefully.

      2. Use properties instead of visible instance fields.

      3. Follow the same naming conventions accross the solution.

      4. Remove unwanted commented code, Indent code properly.

      5. Use curly braces with in an if statement, even if there is a single statement in the if block. This will provide better readability.

      6. Make sure to refactor your code to move the duplicated code to common reusable functions.

      7. Move one time control settings into the .aspx page rather than having them in the code behind in if(!IsPostback) block.

      8. Use inheritance in AuditProvider class which enables code reuse and also reduces the amount of code we have to write and test.

      9. Move the reusable javascript functions to an external .js file instead of having them on the page.

      10. For controls that are declarativley specified on the page, tie the event handlers to the controls events on the aspx page rather than initializing them in the codebehind. If the controls are built dynamically then we donot have a choice.

      11. Make sure to check for nulls when using any type retrieved from a session, querystring or a database to avoid NullReferenceExceptions.

      12. Use foreach loop instead of using for loop which may lead to out of boundary run time exceptions.

       

       

       

       

       

       

       

       

       

       

       

      Layered Architecture

      6 Apr

                                                           Cross Section of Tiers

      This cross section depicts 6 layers and a database at the bottom. However, it is still referred to as a 3-tier architecture. On the left the letters P, B, and D represent these 3 tiers: Presentation, Business, and Data tier respectively. Some of these tier consist of more than one layer which in the figure above is indicated by two letter acronyms: CL (Client Layer), PL (Presentation Layer), HL (Hosting Layer), SL (Service Layer), BL (Business Layer), and DL (Data Access Layer) respectively.

      CREATE RESTful WCF Service API Using POST

      6 Apr

      Introduction

      WCF Restful service using HTTP Get method works well as long as you are sending small data as information to the service. But if want to deliver huge data, HTTP GET Method is not a good choice. In this article, we will create one WCF RESTFul POST API. I will also try to explain why and where to use POST method.

      Why to use POST, not GET?

      When I write any WCF service, I always use POST. The reason is the advantage of POST over GET. Using HTTP POST method, you can almost achieve everything which you can achieve from GET. Despite this, you will get some additional feature if using POST. We might say that “GET” is basically for just getting (retrieving) data whereas “POST” may involve anything, like storing or updating data, or ordering a product, or sending E-mail, etc.

      POST

      1. Easy Character Encoding using application/x-www-form-urlencoded
      2. No Proxy by default so always actual data from web server
      3. Data length can be restricted by webserver, not by browser

      GET

      1. Character encoding will reduce the amount of data that can be used because of URL encoding entities (i.e. three Japanese characters are converted to this: %26%2312454%3B%26%2312455%3B%26%2312502%3B)
      2. Running an HTTP request with GET can be cached on your web browser or a configured proxy server
      3. Maximum URL length is 2,083 characters in Internet Explorer (see MaxClientRequestBuffer: Use POST instead of GET to send large amounts of data in request)

      and lot more…

      Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browser. Sending long information via URL is not a good way of implementation and also it has many restrictions, i.e., max length of URL, information format, bla bla bla. For example, Internet Explorer has a limitation implemented at 2083 characters. URI is meant to be readable not to send information.

      So if you are writing any REST service and your information is long enough, better to choose POST instead of GET method.

      In this article, I am going to create WCF Restful service using POST method and access it using HTTP Request. So we will have client and server both in this example code. I am creating one service which accepts HTTP Post XML request and response request data in XML format.

      Step by Step Guide

      STEP 1

      Launch Visual Studio 2010. Click FILE->NEW->PROJECT. Create new “WCF Service Application“.

      STEP 2

      Once you create the project, you can see in solution that by default WCF service and interface file are already created. Delete by default created file as we will create our own interface and WCF service file.

      Step-2

      STEP 3

      Now right click on solution and create one new WCF service file. I have given name to the service file as “RestServiceImpl.svc”.

      STEP 4

      We will create two DataContract classes for request and response purposes.

      Step-4

      RequestData will receive the request from the client and ResponseData response. One very important thing is that POST XML format to the service should be the same as RequestData. So the post XML request format can be like below:

      Step-4

      We must have to use namespace for the data contract in POST RESTFul service, which has multiple uses, i.e., reflects the current version of your code. The same namespace should use in XML to Post data. Here, I have given http://www.eysnap.com/mPlayer as namespace which can be changed.

      STEP 5

      Now we will write the OperationContract in IRestServiceImpl which is an interface. Below is the code for that.

      As we can see in the above code, here Request and Response format is XML. We can change it to JSON also by changing the WebMessageFormat from WebMessageFormat.Xml to WebMessageFormat.Json.

      STEP 6

      Implementation of Auth OperationContract in RestServiceImpl.svc.cs here.

      STEP-6

      STEP 7

      Now let’s move to the configuration part which is the last one. There will be two basic parts of the configurations file which we must have to understand.

      Services

      Behaviors

      And that’s it. Our Restful WCF POST RESTful service is ready to test.

      SERVICE IS READY

      I have created one Test WebClient in C# which makes HTTP request with some XML data. My application is hosted on localhost and URL is http://localhost:35798/RestServiceImpl.svc/auth. I launched and invoked service using WebClient. Below is my XML response which is the correct one.

      This service can be used by any language application (.NET, PHP, JAVA, etc.) and that is the major reason to use REST service in the application.

      Hope the article is useful for the community. Comments, suggestions and criticisms are all welcome.
      Thanks.