Business objects created in .NET are packaged in the form of assemblies, which store all the information required for deploying and versioning a component. The /out option specifies the name of the output file to be created. In this case, the name of the resulting file is Calcnetamt.dll. Finally, you specify the file to be compiled as Calcnetamt.vb.
Creating a data -centric business rule object
For creating a data-centric business rule object, the steps will be similar to those in case of UI-centric business objects. l create a simple reusable datacentric business rule object that establishes a connection with the specified server and sends the queries to the database server.
Creating a data access component by using Data controls of ASP.NET
ASP.NET provides you with Data controls that enable you to create data-centric business rule objects in an easier way without having to type the code manually. This object will be responsible for establishing a connection with the database and returning all necessary data.
Deploying Business Objects
Deployment refers to the process of distributing an application or a component for installation on other machines. The .NET Framework has introduced several new features to simplify the deployment of business objects. Until now, Microsoft's Component Object Model (COM) has been used for creating business objects. However, COM suffers from various problems relating to deployment:
Registration:
When you install a COM component on your machine, the component makes some entries that store information about the component in the Windows Registry database. This information includes the Globally Unique Identifier (GUID) and the Class Identifier (CLSID).
Thus, the process of deploying COM components involves the task of copying necessary files to the disk and making Registry entries. This separation of entries to the disk and Registry causes difficulty in the task of replicating and uninstalling applications. Moreover, the registration of components complicates the task of deploying an application, because each client machine must have appropriate entries in the Registry for using the component.
Versioning:
Often, you have various applications attempting to use the same COM component. When you install a new application, it may result in installing the newer version of the component. In this case, the newly installed application may work well. However, the existing applications that depend on the older version of the component may stop functioning.
These problems occur because the system does not keep track of the versions of different components used by different applications. In addition, the applications do not specify the information about the version of a component that it uses.
To solve these problems, Microsoft has introduced assemblies in .NET. An assembly is a single deployable unit that includes all the information required to deploy a component. An assembly can be embedded within a single DLL. In such a case, it is called a singlefile assembly.
An assembly can also be made up of multiple files. In such a case, the assembly is called a multifile assembly. Assemblies are used as the basic building blocks for solving the issues relating to registration and versioning. You can think of an assembly as a logical DLL. However, a DLL is dependent on the Registry for maintaining information about it, whereas an assembly maintains all information about itself and does not depend on any Registry entries.
Assemblies have the following features:
They are self-describing: Assemblies are self-describing deployable units.
.NET stores the metadata about the components in assembly manifests, which include the identity of the assembly (such as the name and the version number), security information, information about the dependencies, and the list of files that constitute the assembly. In .NET, an application is also made up of assemblies. Therefore, the information about the version of a component used by an application is also maintained in the assembly.
They record the version information and enforce it at run time: The assembly manifest also includes the information about the dependencies between different assemblies, such as the name of the referenced assembly and its version number. This version number is used at run time to ensure that the correct version of the dependency is loaded.
They provide the ability to work with side-by-side components:
This feature allows multiple versions of a component to be installed and run simultaneously. The caller of the assembly can specify the version to be loaded. Thus, the .NET Framework allows multiple versions of a single component to coexist on a machine. This feature also isolates the application from the changes made to the system by other applications.
RELATED POST
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
Creating a data -centric business rule object
For creating a data-centric business rule object, the steps will be similar to those in case of UI-centric business objects. l create a simple reusable datacentric business rule object that establishes a connection with the specified server and sends the queries to the database server.
Creating a data access component by using Data controls of ASP.NET
ASP.NET provides you with Data controls that enable you to create data-centric business rule objects in an easier way without having to type the code manually. This object will be responsible for establishing a connection with the database and returning all necessary data.
Deploying Business Objects
Deployment refers to the process of distributing an application or a component for installation on other machines. The .NET Framework has introduced several new features to simplify the deployment of business objects. Until now, Microsoft's Component Object Model (COM) has been used for creating business objects. However, COM suffers from various problems relating to deployment:
Registration:
When you install a COM component on your machine, the component makes some entries that store information about the component in the Windows Registry database. This information includes the Globally Unique Identifier (GUID) and the Class Identifier (CLSID).
Thus, the process of deploying COM components involves the task of copying necessary files to the disk and making Registry entries. This separation of entries to the disk and Registry causes difficulty in the task of replicating and uninstalling applications. Moreover, the registration of components complicates the task of deploying an application, because each client machine must have appropriate entries in the Registry for using the component.
Versioning:
Often, you have various applications attempting to use the same COM component. When you install a new application, it may result in installing the newer version of the component. In this case, the newly installed application may work well. However, the existing applications that depend on the older version of the component may stop functioning.
These problems occur because the system does not keep track of the versions of different components used by different applications. In addition, the applications do not specify the information about the version of a component that it uses.
To solve these problems, Microsoft has introduced assemblies in .NET. An assembly is a single deployable unit that includes all the information required to deploy a component. An assembly can be embedded within a single DLL. In such a case, it is called a singlefile assembly.
An assembly can also be made up of multiple files. In such a case, the assembly is called a multifile assembly. Assemblies are used as the basic building blocks for solving the issues relating to registration and versioning. You can think of an assembly as a logical DLL. However, a DLL is dependent on the Registry for maintaining information about it, whereas an assembly maintains all information about itself and does not depend on any Registry entries.
Assemblies have the following features:
They are self-describing: Assemblies are self-describing deployable units.
.NET stores the metadata about the components in assembly manifests, which include the identity of the assembly (such as the name and the version number), security information, information about the dependencies, and the list of files that constitute the assembly. In .NET, an application is also made up of assemblies. Therefore, the information about the version of a component used by an application is also maintained in the assembly.
They record the version information and enforce it at run time: The assembly manifest also includes the information about the dependencies between different assemblies, such as the name of the referenced assembly and its version number. This version number is used at run time to ensure that the correct version of the dependency is loaded.
They provide the ability to work with side-by-side components:
This feature allows multiple versions of a component to be installed and run simultaneously. The caller of the assembly can specify the version to be loaded. Thus, the .NET Framework allows multiple versions of a single component to coexist on a machine. This feature also isolates the application from the changes made to the system by other applications.
RELATED POST
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
No comments:
Post a Comment