The .NET Framework 3.5 provides the foundation for building connected and appealing applications, productively, on a wide variety of systems from the device to the data center.

Microsoft continues to support developers using the .NET Framework platform by providing support for applications built in previous versions to the 3.5 release, so existing applications built for .NET Framework 2.0 or .NET Framework 3.0 will continue to work.

• Deep integration of Language Integrated Query (LINQ) and data awareness.
• Support for Web 2.0 AJAX-style applications and services in ASP.NET and WCF.
• Full tooling support for WF, Windows Communication Foundation (WCF), and Windows Presentation Foundation (WPF), including the new workflow-enabled services technology.
• New classes in the base class library (BCL) for the .NET Framework 3.5 address the most common customer requests.

• Presentation Layer
• Business Logic Layer
• Data Access Layer

In most of the cases the data entered by the end user needs some kind of validation or further processing. This is the responsibility of Business Logic Layer.

Finally, your application data needs to be stored and retrieved in some data store (RDBMS, XML etc.). This task is handled by Data Access Layer.

In short, the process works like this:

• User requests for some application data.
• The data access layer retrieves the data and is forwarded to the presentation layer via business logic layer. Sometimes data access layer gives this data directly to presentation layer.
• Presentation layer receives the data to be displayed via business logic layer.
• The user changes the data and initiates the appropriate action (such as insert, or update).
• The business logic layer validates the data submitted by the user.
• If the data is valid it is handed over to data access layer for updating into the database.

• The applications gets divided in logically isolated pieces reducing tight coupling between the UI, business processes and database.
• Change in the underlying database and data access methods do not have any effect on the presentation layer or client application.
• Client application no longer has SQL statements embedded in it. This makes it de-coupled from rest of the application.
• Table and column names can be effectively eliminated from the client-side code.
• The client application is unaware from where data comes (location transparency).
• It becomes easier to modify or extend your application, without breaking or recompiling the client-side code.

A boxing conversion permits any value-type to be implicitly converted to the type object or to any
interface-type implemented by the value-type. Boxing a value of a value-type consists of allocating an object instance and copying the value-type
value into that instance.

For example any value-type H, the boxing class would be declared as follows:

class vBox
{
  H value;
  H_Box(H h)
  {
   value = h;
  }
}

Boxing of a value v of type H now consists of executing the expression new H_Box(v), and returning the
resulting instance as a value of type object.
Thus, the statements
int i = 12;
object box = i;

conceptually correspond to
int i = 12;
object box = new int_Box(i);

Boxing classes like H_Box and int_Box above don't actually exist and the dynamic type of a boxed value
isn't actually a class type. Instead, a boxed value of type G has the dynamic type G, and a dynamic type check using the is operator can simply reference type G.

For example,

int i = 12;
object box = i;
if (box is int)
{
  Console.Write("Box contains an int");
}

will output the string  Box contains an int on the console.

A boxing conversion implies making a copy of the value being boxed. This is different from a conversion
of a reference-type to type object, in which the value continues to reference the same instance and
simply is regarded as the less derived type object.

For example, given the declaration

struct Point
{
  public int x, y;
  public Point(int x, int y)
  {
    this.x = x;
    this.y = y;
  }
}

the following statements
Point p = new Point(10, 10);
object box = p;
p.x = 20;
Console.Write(((Point)box).x);
will output the value 10 on the console because the implicit boxing operation that occurs in the
assignment of p to box causes the value of p to be copied. Had Point instead been declared a class, the
value 20 would be output because p and box would reference the same instance.