Migrating to .NET from existing languages and platforms has been made much easier. Especially if that environment is COM or Java. COM, Interop is built into the framework, and C# will be very familiar for those developing in Java currently. In fact, Microsoft has a migration utility to automatically migrate existing Java source code into C#.

 Common language runtime (CLR)

 This is the engine that is shared among all languages supported in .NET, including C#, VB.NET, Managed C++, J#, and others to come.
 With the help of the CLR, the developer can write base classes in VB.NET, child classes in C#, and aggregate this tree from Managed C++ (this is just one example). You choose the language during implementation.

 Base class library (BCL)

 What makes Java so appealing besides the managed environment and cross-platform support is its class library. The .NET framework takes the class library concept a step further by supporting it across any language and extensible for future platform variances. Now BCL-supported features such as remoting, string manipulation, exception handling, and collection management construct is the same from any language conforming to the CLI.

 Common type system (CTS)

 This addresses the supported data types within the framework and how they are represented in metadata format. Each supported .NET language need only support a subset of the total data type set. Typically, it will be those types used most frequently (e.g., integer, short, long, string, char, boolean, object, interface, struct, etc.)

 Simplified deployment

 Say goodbye to DLL hell and the nightmare of Windows registration. Applications can now be deployed by a simple XCOPY of the assemblies, ASP.net files, and configuration files.

 Full Web service and SOAP support

 Complexities are optionally hidden for building Web service providers and consumers in .NET. Details of the syntax and protocol surrounding XML Web services can be fully customized if needed, however. It is truly the best of both worlds.

 XML at the core

 Serialization, streaming, parsing, transforming, and schema support are only some of the “baked-in” XML features of the .NET runtime.

 Object-oriented ASP.NET

 Use script for your clients, not your server-based code! Leverage your existing OO framework from ASP.NET and enjoy improved Web application performance due to compiled server code.

1.  Clean application code— Application code that is replete with data access details is difficult to read and maintain. Application logic tends to become obscured by the many calls necessary to do even simple database calls. When an application uses a well-designed data accessor abstraction that exposes logical database operations, its code can focus more on its own business logic.
2.  Incorporation of optimization strategies— Data access code usually is a primary analysis focal point when tuning an application’s performance. Data access code is a common bottleneck source and simple optimizations often have significant effects. When data access code is spread across a system, it requires much more effort to apply and measure optimizations because you must repeat their implementations multiple times. When you encapsulate all physical data access code within a data accessor implementation, you can incorporate an optimization strategy once and it immediately applies across the entire system.
3.  Adoption of new database features or platforms— When physical data access code is spread throughout a system, it is hard to add support for new features or platforms because it involves searching the entire code base and replacing or adding new calls where necessary. This process is tedious and error-prone. When a data accessor implementation encapsulates physical data access code, you only have one isolated component to enhance.
4.  Swappable physical data access implementations— You can swap among multiple data accessor implementations without changing application code. This enables you to conveniently support multiple, diverse database platforms and technologies.

 Disadvantages

1.  Limits application control of data access— Application code is limited to the logical operations defined by a data accessor abstraction. When a data accessor abstraction is not well-designed or versatile enough for an application’s data access requirements, the application code may resort to unnatural or awkward workarounds that ultimately lead to unexpected results.

 The initial TTL entry is set by the originator of the packet, and it varies. To be efficient, a routing update will set this field to a 1 (RIP will). Why set it to anything else, when that update is sent only to its local segments? Multicast protocols set it to many different sizes to limit the scope of the multicast. For normal usage, many applications set it to 32 or 64 (2 and 4 times the size of a RIP network). Time to live is a field that is used by routers to ensure that a packet does not endlessly loop around the network. This field (currently defined as the number of seconds) is set at the transmitting station and then, as the datagram passes through each router, it will be decremented. With the speed of today’s routers, the usual decrement is 1. One algorithm is that the receiving router will notice the time a packet arrives, and then, when it is forwarded, the router will decrement the field by the number of seconds the datagram sat in a queue waiting for forwarding. Not all algorithms work this way. A minimum decrement will always be 1. The router that decrements this field to 0 will discard the packet and inform the originator of the datagram (through the ICMP protocol) that the TTL field expired and the datagram did not make it to its destination.

 The time–to–live field may also be set to a certain time (i.e., initialized to a low number like 64) to ensure that a packet stays on the network for only a set time. Some routers allow the network administrator to set a manual entry to decrement. This field may contain any number from 0 to 255 (an 8–bit field).

 The File Transfer Protocol (FTP) is similar to TELNET in terms of control, but this protocol allows for data files to be reliably transferred on the Internet. FTP resides on top of TCP and uses it as its transport mechanism. TFTP is a simplex file transfer protocol (based on an unreliable transport layer called UDP), and is primarily used for boot loading of configuration files across an internet.

 The Simple Mail Transport Protocol (SMTP) is an electronic mail system that is robust enough to run on the entire Internet system. This protocol allows for the exchange of electronic mail between two or more systems on an internet. Along with a system known as Post Office Protocol, individual users can retrieve their mail from centralized mail repositories.

 The Domain Name Service (DNS) is a centralized name service that allows users to establish connections to network stations using human–readable names instead of cryptic network addresses. It provides a name–to–network address translation service. There are many other functions of DNS, including mail server name to IP address translation. Mail service would not exist if not for the DNS.

 The Boot Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) allow for management of IP parameters on a network. These protocols do not provide for router configurations but endstation configurations. BOOTP was the original protocol that provided not only a workstation’s IP address but possibly its operating image as well. DHCP is best known for its management allocation scheme of IP addresses and is a superset of BOOTP that provides extended functions of IP as well as IP address management.

1. Frequency-division multiplexing (FDM). Numerous signals are combined on a single channel. Each signal on the channel is assigned unique frequency for communication. The caller and the receiver tune to the same frequency to communicate. This is similar to how radio stations work. Each has its own frequency band over which it broadcasts. To listen to a particular channel, you tune the receiver to that particular frequency. For person-to-person communication, this is a very inefficient use of spectrum, hence is only used by analog wireless networks.
2. Time-division multiplexing (TDM). As with FDM, numerous signals are combined on a single channel, but with TDM they are divided into separate time slots. The time segments are assigned to an individual user and are rotated at regular intervals. The receiver interprets the appropriate time slot (channel) to receive the information. This technique allows for variation in the number of signals sent along the line, and constantly adjusts the time intervals to maximize bandwidth. Many of the current second-generation wireless systems are based on time-division multiplexing as it provides efficient use of spectrum with minimal interference.
3. Code-division multiplexing (CDM). Rather than dividing the signal using frequency or time, CDM attaches a code to each signal, and sends them all over the same broad spectrum. This results in very high spectrum efficiency and low levels of interference by other signals. Even though all of the signals are being broadcast at once, a receiver will only accept the signals with the right code. This technique is used in several second-generation wireless networks and is the basis for nearly all third-generation networks.

The following are the key advantages of wireless Internet (thin client) architecture:

1.  Minimal to zero software deployment. This allows applications to be deployed without any additional client-side configuration. Updates to these applications are also straightforward since only the server has to be updated.
2.  Extends Internet computing model. Many corporate applications are based on the Internet model. Wireless Internet is a natural extension to these applications.
3.  Familiar user interface. Many users are familiar with a browser interface to their applications. Providing a similar interface on mobile devices allows them to be productive immediately; there is no learning curve.
4.  Enterprise integration. If an existing Internet application is being extended, the application logic and enterprise integration layers may already be taken care of. This is a tremendous benefit, as enterprise integration often proves to be the most resource-intensive part of a mobile application.
5.  Security. All of the data is stored on the server behind corporate firewalls. No data is stored on the client.

Disadvantages

Wireless Internet architectures have some disadvantages as well, namely:

1.  Wireless connectivity. To access any data, all of which resides on the server, you need wireless connectivity. This can be problematic when users are moving between multiple locations. The exception is when browsers have content-caching capabilities. That said, even when caching is available, there is still a very limited amount of data and logic available to perform transactions.
2.  Simple user interface. Many microbrowsers have limited capabilities for graphics or other “rich” components. Graphics are also often avoided to minimize the amount of data being downloaded over potentially slow wireless networks.
3.  Application performance. For each request being transferred over a wireless network, performance can be an issue. This is due partially to network throughput and partially to network latency.
4.  Application testing. Controlling, predicting, and testing the behavior of the application is difficult on the full range of microbrowsers. When emulation software is used to simulate devices, it is not always an accurate representation of the end-user experience since it is not executing over a wireless network.
5.  Availability. If a server-side problem occurs, all users will be brought to a halt.
6.  Security. Total control of the environment is not available in most cases, because a wireless gateway exists that may lead to security concerns.
7.  Cost. Wireless airtime fees can become an issue if the mobile user has to constantly be connected to use the application. On circuit-switched networks, where fees are charged based on the time connected, not the data transferred, charges are incurred even when a user is reading Web content or filling in a form.

One of the main purposes of GPRS is to facilitate the interconnection between a mobile and the other packet-switched networks, which opens the doors to the world of the Internet. With the introduction of packet mode, mobile telephony and Internet converge to become mobile Internet technology. This technology introduced in mobile phones allows users to have access to new value-added services, including:

1. Client-server services, which enable access to data stored in databases. The most famous example of this is access to the World Wide Web (WWW) through a browser.
2. Messaging services, intended for user-to-user communication between individual users via storage servers for message handling. Multimedia Messaging Service (MMS) is an example of a well-known messaging application.
3. Real-time conversational services, which provide bidirectional communication in real-time. A number of Internet and multimedia applications require this scheme such as voice over IP and video conferencing.
4. Tele-action services, which are characterized by short transactions and are required for services such as SMS, electronic monitoring, surveillance systems, and lottery transactions.

1. Procedures are on the server so messages don’t need to go back and forth to the client during the time the procedure is executed.
2. Procedures are parsed once, and the result of the parsing is stored persistently, so there’s no need to reparse for every execution.
3. Procedures are in the catalog so they are retrievable, and procedures are subject to security provisions, in the same way as other SQL data.
4. Procedures are in one place so code sharing is easy, and when changes happen there’s no need to send code changes to clients.

 When you use a stored procedure, you are depending on cache (which is limited) and access to the procedure (which may be serialized). Therefore it is a mistake to use stored procedures too frequently .

Some of the important points we should remember while creating the store procedure are.

1. Don’t declare parameters to be “input/output” when they’re merely “input” parameters.
2. Don’t write stored procedures as if the precompiler has the built-in skills of a compiler. Take things out of loops, fold, put declarations together in one statement, and avoid testing assumptions on your own—don’t expect the DBMS to do these things for you.
3. Shift logic from WHERE clauses to IF clauses whenever possible.
4. If a stored procedure contains an IF statement and is inside a trigger, take the condition out of the IF and put it in the trigger’s WHEN clause.
5. avoid putting COMMIT or ROLLBACK in the stored procedure. The transaction-end statements are especially bad if you’re using distributed transactions and TP monitors

The .NET Framework incorporates the following two complementary security models that address many of the issues associated with user and code security:

1. Code access security (CAS)
2. Role-based security (RBS)

CAS and RBS do not replace or duplicate the security facilities provided by the underlying operating system. They are platform-independent mechanisms that provide additional security capabilities to augment and enhance the overall security of your managed solutions.

CAS uses information about the source and origin of an assembly (evidence) gathered at run time to determine which actions and resources that code from the assembly can access (permissions). The .NET Framework security policy—a hierarchical set of configurable rules—defines the mapping between evidence and permissions. The .NET Framework class library uses permission demands to protect its most important functionality from unauthorized access. A demand forces the common language runtime to ensure that code calling a protected method has a specific permission. CAS ensures that the runtime capabilities of code depend on the level of trust you place in the creator and source of the code, not the level of trust you place in the user running the code.

The StringBuilder class offers a solution by providing a character buffer and allowing you to manipulate its contents without the runtime creating a new object as a result of every change. You can create a new StringBuilder object that’s empty or initialized with the content of an existing String object. You can manipulate the content of the StringBuilder object using overloaded methods that allow you to insert and append string representations of different data types. At any time, you can obtain a String representation of the current content of the StringBuilder by calling StringBuilder.ToString.

Two important properties of the StringBuilder control its behavior as you append new data: Capacity and Length. Capacity represents the size of the StringBuilder buffer, whereas Length represents the length of the buffer’s current content. If you append new data that results in the number of characters in the StringBuilder (Length) exceeding the capacity of the StringBuilder (Capacity), the StringBuilder must allocate a new buffer to hold the data. Used carelessly, this buffer reallocation can negate much of the benefit of using the StringBuilder. If you know the length of data you need to work with, or know an upper limit, you can avoid unnecessary buffer reallocation by specifying the capacity at creation time or setting the Capacity property manually. When setting the Capacity and Length properties, be aware of the following behavior:

1. If you set Capacity to a value less than the value of Length, the Capacity property throws the exception System.ArgumentOutOfRangeException.
2. If you set Length to a value less than the length of the current content, the content is truncated.
3. If you set Length to a value greater than the length of the current content, the buffer is padded with spaces to the specified length. Setting Length to a value greater than Capacity automatically adjusts the Capacity to the same value as the new Length.