Transcript Overview of the Microsoft .NET Framework

Overview of the Microsoft
.NET Framework
Jim Fiddelke, Greenbrier & Russel
Agenda
•
•
•
•
•
•
•
•
•
Overview
The CLR
The Framework Class Library
ASP.NET
Web Forms
Web Services
Data Access
WinForms
Questions and Answers
Overview
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.
The .NET Framework
ASP.NET
Web Services
Windows Forms
Web Forms
ASP.NET Application Services
Controls
Drawing
Windows Application Services
Framework Class Library
ADO.NET
XML
Threading
IO
Network
Security
Diagnostics
Etc.
Common Language Runtime
Memory Management
Common Type System
Lifecycle Monitoring
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 (mid2002) and beyond.
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
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).
.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”.
J2EE: Language-Specific, PlatformIndependent
Linux
Person.java
Java VM
Person
bytecodes
Java VM
Deploy
Address
bytecodes
Windows
Java VM
Company
bytecodes
Solaris
Address.java
Company.java
Java VM
.NET: Language-Independent, PlatformSpecific
Person.vb
Windows
(Visual Basic)
CLR
Person
MSIL
CLR
Deploy
Address
MSIL
Windows
CLR
Company
MSIL
Windows
Address.cs
(C#)
Company.cbl
(Cobol)
CLR
J2EE
•
•
•
•
The core (JVM and standard class libraries) are mature.
2 million Java programmers.
J2EE implementations are not entirely cross-platform.
Java’s 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.
.NET
• Being newer, .NET adds improvements such as native
XML support.
• 6 million VB developers.
• All development and deployment is Windows.
The CLR
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 “UnManaged Code”.
• VB6 is 100% “Un-Managed”, VB.NET is 100%
“Managed”.
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
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 selftuning.
• 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+.
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.
Key Features and Benefits
COM provides a way for
components to integrate.
However, each component must
provide the “plumbing” and
objects cannot directly interact.
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.
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
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 runtime’s 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 fullycompliant 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.
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 type’s members.
Members that your code references.
Other runtime data for the CLR.
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.
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”.
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 component’s 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.
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.
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.
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 module’s MSIL, the component
metadata, and the assembly manifest. In other cases,
the assembly may consist of many DLLs, with the
manifest in it’s own file.
• No MSIL code can ever be executed unless there is a
manifest associated with it.
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.
Packaging: Modules, Types, Assemblies,
and the Manifest
Assembly
Manifest
Module
Metadata
MSIL
Type
Type
Type
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.
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.
The Common Type System
Object
String
Array
ValueType
Int16
Boolean
Int32
Byte
Int64
Char
Single
Currency
Double
DateTime
Decimal
TimeSpan
Primitive Types
Exception
Delegate
Class1
Enum
Multicast
Class2
Delegate
Class3
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.
Error Handling
• Error handling in the CLR is structured and consistent.
• Uses the “Try…Catch…Finally” pattern.
• “Throw” enables you to raise an exception.
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.
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.
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.
The Framework Class Library
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.
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.
Key Features and Benefits
• Cross-Language Interoperability
• Consistent and Unified Programming Model
• Object-Oriented and Extensible Class Library
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.
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.
ASP.NET
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.
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.
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.
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.NET’s 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.
Web Forms
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 sideby-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.
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.
Coding Structure
• Directives appear at the start of the .aspx file.
• Code Declaration Blocks are blocks of code contained in
special <SCRIPT> tags.
• Code Rendering Blocks are code delimited by the
familiar <%…%> 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.
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 page’s controls are maintained
automatically via a hidden form field.
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.
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,
<asp:ListBox> is substituted with <SELECT>.
• Fall into two broad categories: HTML Controls and Web
Controls.
HTML Controls
• Defined in the System.Web.UI.HtmlControls namespace.
• Server-side references to some of the most commonlyused 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 “runat=server” attribute.
• Example:
– <BUTTON OnServerClick=“Button_Click” RunAt=“Server”>
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 <asp:Button>.
• Are rendered to the browser based on the browser’s
capabilities and other factors. For example, the
<asp:Button> control may render as an <INPUT
type=submit> or as a <BUTTON>.
• Can be grouped into five categories:
–
–
–
–
–
Intrinsic controls, such as the ASP:RadioButton.
Rich controls, such as the ASP:Calendar.
List controls, such as ASP:DataGrid.
Validation controls, such as ASP:RangeValidator.
Mobile controls for encapsulating WML for WAP requests
(post beta 1).
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:
–
–
–
–
–
–
ASP:RequiredFieldValidator
ASP:RangeValidator
ASP:CompareValidator
ASP:RegularExpressionValidator
ASP:CustomValidator
ASP:ValidationSummary
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.
Web Services
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 doesn’t 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 Microsoft’s
TerraServer.
Why Use Web Services
• No physical distribution of software. Less cost, easier
maintenance.
• Easier to implement than DCOM, Sun’s 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.
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.
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.
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).
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:
– <%@ WebService Language=“C#” Class=“MyClass” %>
• 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.
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 it’s 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?Parm=Value&NextParm=NextValue…
• Calling the service in this manner will result in a simple
XML response containing the return value.
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:
– <FORM Method=“Post”
Action=“StockTicker.asmx/GetStockPrice”>
• The response is an XML string.
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.
Data Access
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.
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.
ADO.NET Architecture
.NET Data Provider
Connection
DataAdapter
Transaction
Parameters
DataReader
DataTableCollection
DataTable
SelectCommand
Command
DataSet
DataRowCollection
InsertCommand
UpdateCommand
DeleteCommand
DataColumnCollection
ConstraintCollection
DataRelationCollection
Database
XML
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.).
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, readonly stream.
OleDbDataReader / SqlDataReader
• Uses streaming methods, such as Read() to fetch data
rows.
• Very fast, efficient object for read-only scenarios.
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.
The DataSet
• The ADO.NET DataSet object can be described as an inmemory 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.
WinForms
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.
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.
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.
Questions and Answers
www.gr.com/new/introto.net.asp