Overview of the Microsoft .NET Framework

1
Overview of the Microsoft .NET Framework
Jim Fiddelke, Greenbrier Russel
2
Agenda

• Overview
• The CLR
• The Framework Class Library
• ASP.NET
• Web Forms
• Web Services
• Data Access
• WinForms
• Questions and Answers

3
Overview
4
What is .NET

• Three main elements
• The Framework (CLR, FCL, ASP, WinForms)
• The Products (Windows, Visual Studio, Office)
• The Services (My Services)
• Development began in 1998.
• Framework Goals
• Improved reliability and integrated security.
• Simplified development and deployment.
• Unified API, multi-language support.
• New version of COM?
• XML is the .NET Meta-Language.
• All MS server products eventually .NET-enabled.

5
The .NET Framework
Windows Forms
ASP.NET
Web Services
Web Forms
Controls
Drawing
ASP.NET Application Services
Windows Application Services
Framework Class Library
ADO.NET
XML
Threading
IO
Network
Security
Diagnostics
Etc.
Common Language Runtime
Common Type System
Lifecycle Monitoring
Memory Management
6
The .NET Framework

• Beta 1 released Oct, 2000.
• Beta 2 released July, 2001.
• Finalized in Dec, shipping in Feb 2002.
• SDK and Visual Studio.NET (includes SDK) run on
  Windows NT 4.0, 2000, and XP.
• Redistribution Pack (runtime) runs on Windows 98,
  NT 4.0, 2000, ME, and XP.
• Framework will ship with Windows .NET Server
  (mid-2002) and beyond.

7
The New Languages - C and VB.NET

• Performance differences very minor.
• VB.NET introduces long sought-after features
• Inheritance
• Parameterized Class Constructors
• Function Overloading
• Multi-Threading
• Structured Error Handling
• Creating NT Services
• VB.NET not backward compatible with VB6.
• VB6 will be supported until the third release of
  VB.NET (5-6 years away).
• C
• New modern, object-oriented language
• Similar to C/Java
• High-Fidelity language of .NET

8
What About Java?

• Microsoft is developing JUMP (Java User
  Migration Path to .NET). A set of conversion
  tools.
• Late-Breaking News Visual Studio.NET will
  include a Java component called Visual Java.NET
  (or maybe Visual J .NET).

9
.NET vs. J2EE

• Both are similar in many ways
• Server- and client-side model for building
  enterprise applications.
• Virtual machine designed to inspect, load, and
  execute programs in a controlled environment.
• APIs for creating both fat- and thin-client
  models.
• APIs for foundation services (data access,
  directory, remote object calls, sockets, forms).
• Development environment for dynamic web pages.
• J2EE Language-Dependent Platform-Independent.
  
• .NET Language-Independent Platform Dependent.

10
J2EE Language-Specific, Platform- Independent
Person.java
Linux
Java VM
Person bytecodes
Deploy
Windows
Company bytecodes
Address bytecodes
Solaris
Address.java
Company.java
11
.NET Language-Independent, Platform- Specific
Person.vb
Windows
(Visual Basic)
CLR
Person MSIL
Deploy
Windows
Company MSIL
Address MSIL
Windows
Address.cs
(C)
Company.cbl
(Cobol)
12
J2EE

• The core (JVM and standard class libraries) are
  mature.
• 2 million Java programmers.
• J2EE implementations are not entirely
  cross-platform.
• Javas true potential is realized only when all
  (or most) development is done in Java.
• Changing the Java language specification has an
  enormous impact on the entire platform.

13
.NET

• Being newer, .NET adds improvements such as
  native XML support.
• 6 million VB developers.
• All development and deployment is Windows.

14
The CLR
15
What is the CLR

• The CLR is at the core of the .NET platform - the
  execution engine.
• A Managed Execution Environment. Manages the
  execution of code and provides services that make
  development easier.
• Code developed for a compiler that targets this
  platform is referred to as Managed Code.
• Code that relies on COM and the Win32 API is
  Un-Managed Code.
• VB6 is 100 Un-Managed, VB.NET is 100
  Managed.

16
Key Features and Benefits

• Cross-Language Integration
• Cross-Language Inheritance
• Cross-Language Exception Handling
• Enhanced Security
• Versioning and Deployment Support
• Debugging and Profiling Services
• Automatic Memory Allocation and Management
• A Common Type System
• Object Lifecycle Monitoring and Garbage Collection

17
Key Features and Benefits

• Key objective is to handle much of the
  programming infrastructure, such as memory
  management and object proxies. Much is replaced
  by metadata.
• Memory management is self-configuring and
  self-tuning.
• Many common bugs should be eliminated (such as
  memory leaks).
• Tool support - designed to work well with
  designers, wizards, debuggers, etc.
• CLR replaces the existing runtime layers of COM,
  MTS, COM.

18
Key Features and Benefits

• Language interoperability is built into the
  Framework by means of a Common Type system.
• There is a CLR-to-COM interoperability layer.
• Better debuggers - can jump between source across
  different languages.
• Simplified deployment - no more DLL Hell. CLR
  supports side-by-side execution - the ability
  to load and execute multiple versions of the same
  assembly.

19
Key Features and Benefits
COM provides a way for components to integrate.
However, each component must provide the
plumbing and objects cannot directly interact.
20
Key Features and Benefits
CLR
With the .NET CLR, components are built on a
common substrate. No plumbing is needed and
objects can directly interact.
21
Application Types

• The CLR supports the following types of
  applications
• Console
• Windows Forms
• Web Forms
• Web Services
• Service Control Manager Services (NT Services)
• Tools and Utilities
• Components

22
The Common Language Specification

• CLR works with multiple languages - including
  those developed by third parties (approx. 22).
• Each language compiler may support different
  subsets of the runtimes functionality.
• The Common Language Specification (CLS) defines
  the requirements for a .NET component to be
  completely usable by other .NET applications.
• The CLS spec. defines a subset of the CLR types
  and features.
• The Framework Class Library (FCL) itself is
  fully-compliant with the CLS.
• VB.NET is fully CLS compliant.
• C is not - you can create C components that
  expose types not usable by VB.NET.
• There is a compiler directive to force
  CLS-compliance.

23
MSIL and JIT Compilation

• Source code is compiled into MSIL (Microsoft
  Intermediate Language). Similar to Java
  bytecodes - CPU-independent instructions.
• MSIL allows for runtime type-safety and security,
  as well as portable execution platforms (all
  Windows). MSIL code cannot play tricks with
  pointers or illegal type conversions.
• The MSIL architecture results in apps that run in
  one address space - thus much less OS overhead.
• Compilers also produce metadata
• Definitions of each type in your code.
• Signatures of each types members.
• Members that your code references.
• Other runtime data for the CLR.

24
MSIL and JIT Compilation

• Metadata in the load file along with the MSIL
  enables code to be self-describing - no need for
  separate type libraries, IDL, or registry
  entries.
• When code is executed by the CLR, a JIT
  compilation step occurs. Code is compiled
  method-by-method to native machine code.

25
Garbage Collection

• COM manages object lifetimes through reference
  counting. Circular references were a big
  problem.
• CLR manages objects through a process of garbage
  collection. CLR will detect and break down
  circular references.
• COM has deterministic finalization - you know
  that when you release the last reference to an
  object, that object goes away, and can code
  accordingly.
• CLR has non-deterministic finalization.

26
Metadata

• Metadata is generated by the compiler and stored
  in the executable (EXE or DLL).
• Similar to a COM type library - contains
  information that describes the components public
  types (enums, structures, interfaces, and
  classes).
• IDL no longer used.
• No need to define an interface to program against
  a class.
• Interface-based programming still alive and well
  in .NET.
• Metadata includes
• Assembly - name, version, culture, public key,
  exported types, security permissions.
• Base classes and interfaces.

27
Packaging Modules, Types, Assemblies, and the
Manifest

• A module refers to a managed binary, such as an
  EXE or DLL.
• Modules contain definitions of managed types,
  such as classes, interfaces, structures, and
  enumerations.
• An assembly can be defined as one or more modules
  that make up a unit of functionality. Assemblies
  also can contain other files that make up an
  application, such as bitmaps and resource files.
• An assembly is not a physical file.
• An assembly is the the fundamental unit of
  deployment, version control, activation scoping,
  and security permissions.

28
Packaging Modules, Types, Assemblies, and the
Manifest

• An assembly is a set of boundaries
• A security boundary - the unit to which
  permissions are requested and granted.
• A type boundary - the scope of an assembly
  uniquely qualifies the types contained within.
• A reference scope boundary - specifies the types
  that are exposed outside the assembly.
• A version boundary - all types in an assembly are
  versioned together as a unit.

29
Packaging Modules, Types, Assemblies, and the
Manifest

• An assembly contains a manifest, which is a
  catalog of component metadata containing
• Assembly name.
• Version (major, minor, revision, build).
• Assembly file list - all files contained in the
  assembly.
• Type references - mapping the managed types
  included in the assembly with the files that
  contain them.
• Scope - private or shared.
• Referenced assemblies.
• In many cases, an assembly consists of a single
  EXE or DLL - containing the modules MSIL, the
  component metadata, and the assembly manifest.
  In other cases, the assembly may consist of many
  DLLs, with the manifest in its own file.
• No MSIL code can ever be executed unless there is
  a manifest associated with it.

30
Packaging Modules, Types, Assemblies, and the
Manifest

• Two types of assemblies
• Private - Usually deployed in the same directory
  as the client application and used only by a
  single application.
• Shared - Used by any application and usually
  installed in a special Global Assembly Cache.
• Version information from a dependent assembly is
  recorded in a client manifest.

31
Packaging Modules, Types, Assemblies, and the
Manifest
Assembly
Manifest
Module
Metadata
MSIL
Type
Type
Type
32
The Common Type System

• At the core of the Framework is a universal type
  system called the .NET Common Type System (CTS).
• Everything is an object - but efficient.
• It is this CTS that make cross-language
  inheritance possible.
• All types fall into two categories - Value types
  and Reference types.
• Value types contain actual data (cannot be null).
  Stored on the stack. Always initialized.
• Three kinds of value types Primitives,
  structures, and enumerations.
• Language compilers map keywords to the primitive
  types. For example, a C long is mapped to
  System.Int32.

33
The Common Type System

• Reference types are type-safe object pointers.
  Allocated in the managed heap.
• Four kinds of reference types Classes, arrays,
  delegates, and interfaces.
• When instances of value types go out of scope,
  they are instantly destroyed and memory is
  reclaimed.
• When instances of reference types go out of
  scope, they are garbage collected.
• Boxing converting an instance of a value type
  to a reference type. Usually done implicitly
  through parameter passing or variable
  assignments.
• UnBoxing casting a reference type back into a
  value type variable.

34
The Common Type System
Object
Array
String
ValueType
Exception
Delegate
Class1
Primitive Types
Enum
Multicast Delegate
Class2
Int16
Boolean
Class3
Int32
Byte
Int64
Char
Single
Currency
Double
DateTime
Decimal
TimeSpan
35
Attributes

• Attributes in the CLR allow you to add additional
  information to the classes you create. This
  information is read by using the
  System.Reflection classes defined in the
  Framework Class Library.
• One particular example of using attributes is the
  WebMethod attribute used to expose a Web
  Service method.

36
Error Handling

• Error handling in the CLR is structured and
  consistent.
• Uses the TryCatchFinally pattern.
• Throw enables you to raise an exception.

37
Delegates

• A new concept that is central to the programming
  model of the CLR.
• Delegates are like function pointers, but are
  actually type-safe, secure, managed CLR objects.
• The CLR guarantees that a delegate points to a
  valid method.
• You get the benefits of function pointers without
  the dangers.
• Each delegate is based on a single method
  signature.
• Commonly used for callbacks.
• Delegates are basis of event handlers.

38
Deployment

• The CLR does not require registry entries for
  assemblies or managed types.
• Assemblies can be deployed using the Windows
  Installer, Internet Explorer, or XCOPY.
• Apps can be run from a CD with no installation at
  all.
• Side-by-side deployment means you can create new
  versions of an assembly without having to
  maintain backwards compatibility with previous
  versions.
• Both versions of the same assembly can run
  together (in the same address space on the same
  machine) - supporting both old and new clients.

39
The Bigger Picture?

• The CLS and CTS are actually a part of a bigger
  specification called the CLI (Common Language
  Infrastructure).
• The CLI and C have been submitted to the ECMA
  for standardization.
• MSIL and the CLR are simply Microsoft
  implementations of the CLI for Windows.
• Open-Source organizations are developing .NET
  ports for other operating systems.
• MS is helping Corel with a .NET port to FreeBSD.
• The Free Software Foundation and Ximian are
  working on a .NET port to Linux.

40
The Framework Class Library
41
What is the Framework Class Library

• The FCL is a hierarchical class library that can
  be utilized across multiple languages (CLS) and
  platforms (Windows).
• Enables consistent programmatic access to the
  .NET runtime environment.
• Integrates the functionality from existing COM
  and other runtime libraries.
• Windows API, Data Access, XML, etc. all
  accessible in a consistent, simplified, unified
  way.

42
What is the Framework Class Library

• Contains thousands of reusable classes,
  interfaces, and components that can be used for
• Accessing the file system, text files, and
  databases.
• Working with XML.
• Developing components and Web Services.
• Managing application configurations.
• Working with Directory Services, Event Logs,
  Processes, Message Queues, and Timers.
• Handling images and strings.
• Creating and managing threads.
• Accessing assembly metadata and managing the CLR.
• Developing Windows Forms applications.
• Developing Web Forms applications.
• Managing application security.

43
Key Features and Benefits

• Cross-Language Interoperability
• Consistent and Unified Programming Model
• Object-Oriented and Extensible Class Library

44
Namespaces

• A Namespace is a user-defined scope in which
  managed types are defined.
• The FCL is organized into 98 namespaces.
• FCL namespaces are organized in a hierarchy. The
  System namespace is at the topmost level, and
  almost all other namespaces are subordinate.

45
COM InterOp

• Classic COM components can be used in a .NET
  application, and vice-versa.
• ASP.NET and VB.NET still support CreateObject().
• C can call COM servers via the InteropServices
  and Reflection routines.
• Interop layer automatically converts errors
  (HRESULTS) into ComException exceptions.
• The Type Library Importer utility takes a
  standard COM type library and creates an assembly
  containing the equivalent .NET metadata. The
  resulting DLL is essentially a mananged-code face
  on the COM component.
• Best practice is to recompile the components.

46
ASP.NET
47
Key Features and Benefits

• Better Performance.
• Script code replaced by the .NET languages.
• Code is JIT compiled (or pre-compiled).
• Early binding, strong typing, better error
  handling.
• Better Programming Models.
• ASP.NET part of the FCL.
• All ASP code consists of subclassed framework
  classes.
• Less Coding.
• Control state is built-in.
• More data-bound controls.
• Easier to use Components.
• DLLs can be replaced in the procedure cache
  without stopping the site.
• No more COM/MTS registration issues.
• Extensive Caching Features.

48
Configuration

• All configuration is done via an XML file -
  Web.config.
• Web.config files are stored in the same virtual
  directory tree as the rest of the application
  files.
• Can be changed on the fly, or redeployed using
  XCOPY, without stopping the site.
• A Web.config can exist for each application.
  Config files inherit settings from parent config
  files.
• Additional sections and elements can be added for
  application-specific settings.

49
Global.asax

• Replaces (and is completely compatible with) the
  Global.asa file.
• Provides for application-wide event handlers and
  other global logic for the web application.
  Applies to both the Web Forms and Web Services
  programming models.
• Can contain the following
• Application Directives.
• Code Declaration Blocks.
• Server-side Object Tags.
• Server-side Include Directives.

50
Session State Management

• All session state is (by default) stored
  externally from the worker processes in
  dedicated .NET State Server processes running
  as separate NT processes.
• No end-user code, and no live object references
  reside in these processes.
• This process isolation improves ASP.NETs
  reliability.
• State Server can be a separate machine available
  to all web servers in a web farm.
• Session Id strings are 120-bit keys. Passed
  between page requests via either an HTTP cookie
  or a munged URL.
• State Blobs can be stored in SQL Server
  database.

51
Web Forms
52
What are Web Forms

• Web Forms are a new control-based, event-driven
  execution model for web user interfaces.
• Features a drag-and-drop designer (Visual
  Studio 7), more cleanly-encapsulated
  functionality, and less coding compared to ASP.
• Web Forms are pages with .aspx extensions and
  processed by XSPIAPI.DLL. ASP pages still
  processed by ASP.DLL. Thus old and new ASP apps
  can run side-by-side in IIS.
• An ASP.NET page is a class. Inherits from
  System.Web.UI.Page. Constructed and compiled on
  first reference, then stored in the procedure
  cache.

53
Key Features and Benefits

• Stronger separation of content (HTML) and code.
• Designed to work on any browser.
• Easier debugging with a trace facility.
• Page state management handled for you.
• Event-based programming model is cleaner to code.
• Coding can be done in any CLR language.
• Much better performance than ASP.

54
Coding Structure

• Directives appear at the start of the .aspx file.
• Code Declaration Blocks are blocks of code
  contained in special ltSCRIPTgt tags.
• Code Rendering Blocks are code delimited by the
  familiar ltgt tags.
• Code in declaration blocks can alternatively be
  placed in an external source file, using the
  Inherits and Src directives. This is called
  code-behind.
• External page code can be pre-compiled. Omit the
  Src directive and place the DLL in the \bin
  directory.

55
Event-Based Programming Model

• Existing ASP code has little structure.
• ASP.NET uses an event-based model. Events are
  defined for the Page class, which you provide
  code for.
• Various events are fired, on the server, by the
  controls.
• A post-back occurs as a result of a UI event,
  such as a button click.
• The state of the pages controls are maintained
  automatically via a hidden form field.

56
Page Lifecycle

• ASP.NET Web Form pages go through a series of
  processing stages at which points you can connect
  event-handler code.
• Some commonly-used phases
• Configuration (Page_Load). Page and control view
  state are restored (or initialized). You can
  check the IsPostBack property.
• Event Handling. Many controls will trigger a
  postback and their corresponding events are
  fired. Other controls may not trigger the
  postback, but their relevant events still fire on
  the server when the postback occurs.
• Cleanup (Page_UnLoad). The page has finished
  rendering.

57
Server Controls

• Server controls are HTML elements contained in a
  FORM that remember their state between page
  requests, and generate events which are processed
  on the server.
• In some cases, they use new tag names that are
  recognized by ASP.NET but are substituted with
  standard HTML tags for the browser. For example,
  ltaspListBoxgt is substituted with ltSELECTgt.
• Fall into two broad categories HTML Controls and
  Web Controls.

58
HTML Controls

• Defined in the System.Web.UI.HtmlControls
  namespace.
• Server-side references to some of the most
  commonly-used standard HTML elements.
• Object model for these controls maps very closely
  to the corresponding HTML element.
• Declared using the standard HTML tags, but with
  the addition of the runatserver attribute.
• Example
• ltBUTTON OnServerClickButton_Click
  RunAtServergt

59
Web Controls

• Defined in the System.Web.UI.WebControls
  namespace.
• These are enhanced server-side controls, and do
  not necessarily map one-to-one with HTML elements
• Declared using XML tags such as ltaspButtongt.
• Are rendered to the browser based on the
  browsers capabilities and other factors. For
  example, the ltaspButtongt control may render as
  an ltINPUT typesubmitgt or as a ltBUTTONgt.
• Can be grouped into five categories
• Intrinsic controls, such as the ASPRadioButton.
• Rich controls, such as the ASPCalendar.
• List controls, such as ASPDataGrid.
• Validation controls, such as ASPRangeValidator.
• Mobile controls for encapsulating WML for WAP
  requests (post beta 1).

60
Validation Controls

• Used to validate the contents of other controls.
• Rendered as client-side script if the browser
  supports it, else server-side.
• Server-side validation can be forced by setting
  the EnableClientScript property to false.
• Validation controls are
• ASPRequiredFieldValidator
• ASPRangeValidator
• ASPCompareValidator
• ASPRegularExpressionValidator
• ASPCustomValidator
• ASPValidationSummary

61
User Controls

• User Controls are formed by encapsulating other
  ASP.NET server controls into a composite control.
• Great way of extending ASP.NET, promoting reuse
  of server-side code, and is more object-oriented
  than using include files.
• Controls created in this fashion are identified
  by a namespace, avoiding name collisions.

62
Web Services
63
What are Web Services

• Software as a Service.
• Internet communication is abstracted.
• Programmable components that provide business
  logic to web or desktop applications using XML
  for message formatting and the standard Internet
  protocols (HTTP, SSL, etc.) for communications
  (SOAP).
• Not a new concept - and .NET is not required to
  build SOAP servers or clients. The MS vision is
  simply that .NET becomes the easiest way (thus
  most popular).
• MS doesnt own the standards.
• Part of the .NET initiative is My Services
  (formerly known as Hailstorm), which are a set
  of Microsoft .NET Foundation Web Services. The
  first example of this is Passport. Another good
  example is Microsofts TerraServer.

64
Why Use Web Services

• No physical distribution of software. Less cost,
  easier maintenance.
• Easier to implement than DCOM, Suns RMI, CORBA.
  Web Services do not rely on any proprietary
  standards or platform.
• Designed with a loose-coupling between the
  service provider and the service consumer. One
  can run without the other.
• XML is the defacto standard for data
  interoperability.

65
Web Service Wire Formats

• Web Services use the standard Internet
  communication protocols. This enables basic
  communication between providers and consumers,
  regardless of platform.
• This is SOAP (Simple Object Access Protocol).
• SOAP is a messaging protocol that uses XML for
  formatting service requests and replies.
• SOAP defines an envelope formatting and
  processing mechanism for complex message
  structures and allows for loose coupling.

66
Web Service Description

• A Web Service Description defines all the
  supported methods that a Web Service provides.
• This is WSDL (Web Service Description Language).
• WSDL is an XML grammar that developers and
  development tools use to represent the
  capabilities and syntax of a Web Service.
• The .NET Framework has utilities for dealing with
  WSDL, such as Wsdl.exe.

67
Web Service Discovery

• This is the aspect of making the presence and
  capabilities of a Web Service known to the world.
• This is the UDDI (Universal Discovery,
  Description, and Integration) business registry
  service.
• Initiated by Ariba, IBM, and Microsoft.
  Supported by more than 130 companies.
• Provides a standard place to register Web
  Services. Check out www.uddi.org.
• UDDI is a specification built on SOAP/XML and
  defines a document format and protocol for
  searching and retrieving discovery documents -
  which in turn link to DISCO documents.
• DISCO (Discovery of Web Services) is a Microsoft
  protocol for retrieving the contracts for Web
  Services (WDSL documents).

68
Building a Web Service

• Incredibly easy using the .NET Framework. Start
  by opening a new Visual Studio Web Service
  project, or simply code from scratch in Notepad.
• Like Web Forms, Web Services are part of ASP.NET.
  You create your Web Service as an .asmx file
  with the following directive
• lt_at_ WebService LanguageC ClassMyClass gt
• Code can be in any .NET language. Code can be in
  the .asmx file or in a separate module.
• Your class always inherits from
  System.Web.Services.WebService.
• To expose a method, you use the WebMethod
  attribute and make the method public.

69
Calling a Web Service via HTTP Get

• By requesting a Web Service URL from the IE
  Address field, ASP.NET will respond with a
  neatly-formatted page that describes the Web
  Service and its methods. This page even
  provides a simple means to run the methods.
• This is not UDDI or DISCO. Just a
  nicely-formatted page built from the metadata.
• You can get the WSDL by appending ?wsdl to the
  URL.
• To call a method, append the method name and
  parameters to the URL like this
• /MethodName?ParmValueNextParmNextValue
• Calling the service in this manner will result in
  a simple XML response containing the return value.

70
Calling a Web Service via HTTP Post

• The WSDL describes the requirements for doing
  this.
• The Web Service expects that the incoming
  parameter values be contained in FORM fields with
  specific names. Therefore, your FORM has to
  contain INPUT elements named according to the
  WSDL. The ACTION attribute names the method
• ltFORM MethodPost ActionStockTicker.asmx/GetSt
  ockPricegt
• The response is an XML string.

71
Calling a Web Service via SOAP

• Using SOAP is the most comprehensive manner to
  invoke a Web Service, but can be complicated.
• Fortunately, the .NET Framework provides
  utilities to make this easier.
• You build a proxy class which is a mirror image
  of the Web Service. It is run locally on your
  system, and appears to your application as the
  Web Service.
• The proxy handles the SOAP communications with
  the actual Web Service.
• You generate the proxy class using the Web
  Services Description Language tool (wsdl.exe).
• Note that Visual Studio will do this for you
  simply by adding a Web Reference to your
  project.

72
Data Access
73
ADO.NET

• ADO.NET is the primary library for building
  database solutions within the .NET Framework.
• ADO.NET does not replace ADO. ADO and OLEDB are
  still the preferred means for building COM
  applications.
• ADO.NET specifically designed to build
  highly-scalable applications using a 3-tiered,
  connectionless model.
• Better support for offline applications.
• Most of the time in ADO.NET you are working with
  objects that have no active database connection.
• ADO.NET is based on XML.

74
ADO.NET

• The ADO.NET objects are implemented in the
  following namespaces
• System.Data - Base ADO.NET objects and types.
• System.Data.Common - Classes shared by the .NET
  data providers.
• System.Data.OleDb - OLEDB .NET data provider.
• System.Data.SqlClient - SQL Server .NET data
  provider.
• System.Data.SqlTypes - Native SQL Server data
  types.
• System.Data.OleDb and System.Data.SqlClient
  contain roughly the same classes.
• System.Data.OleDb is for using OLEDB data
  sources, like ADO is used for now.
• System.Data.SqlClient is specifically for SQL
  Server, and is highly optimized for performance.

75
ADO.NET Architecture
Database
XML
76
OleDbConnection / SqlConnection

• These classes represent an open connection to a
  data source.
• Provide the same service as the ADO Connection
  object.
• Feature the familiar properties
  (ConnectionString, etc.) and methods (Open,
  BeginTransaction, Close, etc.).

77
OleDbCommand / SqlCommand

• These classes represent a query command to be
  made against a data source.
• Mirrors the ADO Command object with one very big
  difference Data that is returned from SELECT
  statements is obtained via an OleDbDataReader or
  SqlDataReader, which is always a forward-only,
  read-only stream.

78
OleDbDataReader / SqlDataReader

• Uses streaming methods, such as Read() to fetch
  data rows.
• Very fast, efficient object for read-only
  scenarios.

79
OleDbDataAdapter / SqlDataAdapter

• Represent a set of data commands and a database
  connection which are used to fill a DataSet and
  update the corresponding database.
• These objects are used for stateless batch update
  scenarios.
• Select, Insert, Update, and Delete commands are
  grouped together in one composite object.
• Used to interface a database with a DataSet
  object.

80
The DataSet

• The ADO.NET DataSet object can be described as an
  in-memory database.
• A DataSet object can contain a hierarchy of
  objects that represent tables, relationships,
  columns, rows, and constraints.
• It is not tied to any database product.
• The child objects can be manipulated in many
  ways. Not only can the data be updated, but
  additional child objects (tables, relationships,
  rows, etc.) can be created.
• The DataSet has been designed as the
  connectionless workhorse for the framework,
  servicing the need to bridge the Business Logic
  and Data Access layers in a multi-tiered
  implementation.

81
WinForms
82
What are WinForms

• The new way to produce standard Windows desktop
  applications.
• Based on the Windows Foundation Class (WFC)
  produced for Visual J.
• All WinForm applications that you create are done
  by subclassing the .NET base classes.
• Can be written in any .NET language.
• Visual Studio 7 supplies designers for RAD.
• Merges the drag-and-drop RAD spirit of VB with
  the inheritance/reuse/power of MFC.

83
Key Features and Benefits

• Like any other .NET application, WinForm
  applications can be deployed with a simple XCOPY.
  No registration of controls, etc.
• Full integration with the .NET Framework. You
  have all the features of the FCL available for
  your desktop applications, including Web
  Services.
• Visual Inheritance. WinForms are .NET classes.
  Like any other CLR managed type, your classes can
  inherit from other classes.
• Can still use ActiveX controls.

84
The Framework

• WinForms begin at the System.WinForms namespace.
• This namespace contains the Form class and many
  controls that can be added to forms to create
  user interfaces.
• System.WinForms contains the Application class,
  with a static method called Run. This displays a
  form and provides the message pump.
• The Form class is the base class for all forms
  you create.

85
Questions and Answers
www.gr.com/new/introto.net.asp