You are on page 1of 12

1. Introduction to ASP.

NET:

a. Your First ASP.NET Program

b. Event-driven Programming

2. Basic Controls:

a. Understanding Controls

b. Buttons

c. Textboxes

d. Image and Link buttons

e. Checkboxes & Radio Buttons

f. DropDown Menus & ListBoxes

3. Writing Applications

a. Code-Behind

b. Sessions

c. Application Design

d. Configuration

e. User Controls

f. Visual Studio

4. Accessing Data

a. Data Binding

b. Data Grids

c. Data Base Access

C#

1) Understanding C# Language Fundamentals

a. Understanding the Fundamentals of a C# Program

b. Using C# Predefined Types

c. Writing Expressions

d. Creating Conditional Statements

e. Creating Iteration Statements

2) Creating Objects in C#

f. Defining a Class

g. Declaring Methods

h. Using Constructors

i. Using Static Class Members

3) Programming with C#

j. Using Arrays

k. Using Collections

l. Using Interfaces

m. Using Exception Handling

An Introduction to RDBMS Basic SQL Statements Restricting and Sorting Data SQL Functions SQL LAB-1 SQL Joins Subqueries Data Manipulation Language (SQL) SQL LAB-2 SQL LAB-3 Creating and Managing Tables Constarints in SQL Views - SQL Creating DataBase Objects Controlling User Access SQL LAB-4 SQL LAB-5

Class 1: Why Patterns and Introduction to UML

This chapter discusses the reasons why you should study design patterns. Design patterns offer the ability to reuse solutions, not just code. By reusing already established designs, you get a head start on problems and avoid gotchas, you benefit by learning from the experience of others, and you dont have to reinvent solutions for commonly recurring problems. Design

Class 2: Singleton and Factory

Singleton Few solutions require the use of a single object instance across the whole solution, for example naming services or cached objects. This chapter will introduce the singleton pattern as a solution, along with variations for thread safety, and other varieties of single instance based on thread affinity.

Factory There are occasions when you want to decouple the knowledge of which type to create from the client code that creates that type. Factories allow you do this by encapsulating the necessary knowledge of how to create the object thus allowing the actual implementation used to vary at runtime. Factories are useful for building pluggable architectures and for creating application

Class 3: Decorator and Observer

Decorator One of the key design pattern goals is to write code that is closed for modification and open to extension. This pattern shows that an objects behavior and responsibilities can be extended at runtime, as opposed to design time using inheritance. This allows us to combine a variety of behaviors far more efficiently that normal inheritance. Examples of decorators in the

Observer The ability to notify interested entities of changes to an object state is a fundamental requirement of most object-oriented solutions. There are many ways to do this, but there is a danger that we will build a tightly coupled system and we prefer to build a loosely coupled system. The typical way of implementing the observer pattern is to use interfaces, but here we show

Class 4: Strategies and Templates What we can be 100% sure of with software is that it constantly needs to evolve. What we also know is every time we change existing working code there is a risk that we break it. What we need is an approach that allows the software to evolve without having to modify existing working code. The strategy and template patterns allow us to build solutions that can evolve without

Class 5: Command I and Command II and State

Command I In this chapter, we examine the command pattern. The command pattern allows us to encapsulate invocation, allowing the invoker to be decoupled from the client and the recipient, this enables us to build a variety of different invokers to deliver custom thread pooling, and invocation logging to build fault tolerant solutions.

Command II In this chapter we extend the command pattern to not only encapsulate forward invocation but also undo invocation, allowing us to build a complex undo sequence through a series of simple undo commands. This pattern can then be combined with transaction support inside .NET to build transaction aware types.

State In many cases object behavior depends on the state an object is in. When the state of an object changes the behavior of the object also changes. This is typically modeled through the use of finite state machine. This pattern provides a means to map a finite state machine into a series of classes where each class represents a different state, thus providing different behaviors.

Class 6: Adapter and Facade Client's code is often written against a specific interface. As classes evolve, interfaces may change and the client needs a way to adapt to the changing interface. If there are many clients this would result in a lot of dangerous change. The adapter pattern solves this problem by building an adapter that can convert calls from one type hierarchy to another. Facade allows us to

Class 7: Iterator, Composite, and Visitor There is often a need to touch and process every object inside an object hierarchy, for example walking over user interface control objects, XML documents, business entities, file systems, etc. The iterator pattern provides a standard means to achieve this. .NET provides a standard implementation of iterator, further the C# language simplifies the implementation further

Class 8: Anti Pattern and Best Practices

During software development, we often come across common recurring problems in our code. These can be categorized as anti patterns. In t

rized as anti patterns. In this chapter, we will look at common anti patterns and how to fix them and avoid them.