UML 101

So you need to read the entire UML book in 20 minutes. What do you do? These are the excerpts from the Unified Modeling Language Reference Manual I was reading and thought I could summarize for a quick refresh.

 

Aggregation and composition:

Generalization:

Kinds of dependencies:

Use case diagram:

Kinds of Use Case relationships:

Activity Diagram:

Sequence diagrams and Activation:

Component Diagram:

Deployment Diagram:

Packages and relationships:

Left outer join in Entity Framework

This evening I heard someone say that Left Outer Joins are not possible in Entity Framework or perhaps Left Outer Joins are possible, but they bring in all the data and then filter out the right table.

I felt an urge to argue, but I resisted. I thought I would investigate before I waste time. I came up with some articles pretty quickly.

1. Left Outer Join in LINQ
2. Left Outer Join using Inverse Navigation Property
3. DefiningQuery Element
4. Left Outer Join in LINQ to SQL
5. LINQ to Entities with Multiple Left Outer Joins

I am sure these should resolve all questions related to Left Outer Joins.

Now about the performance and the question about how the data is brought, I am pretty sure we can prove that LINQ Queries all support deferred execution. But we can always prove that using the SQL Query Profiler.

Hope this helps.

Singleton Vs. Static Class

Well I was asked this question once. “What is a singleton design pattern and why should I use it? Why not use a static class instead?”

And it was quite surprising how it went. I said that Singleton is used when you need to maintain state. Static classes are used when you want to club together a bunch of stateless methods that do something irrespective of which instance calls these methods. Math class is a good example.

So he asked me, can I not maintain state in a static class? So I said if you want to instantiate something in a static class how would you do it? And surprisingly he told me that he would do it in a static constructor. I asked him, is it possible to instantiate anything in the static constructor or even declare an instance type in a static class? And he asked me is it not possible? I said it is not as far as I know and he asked me if I am sure.

Now the way the questions were asked about this subject, I was quite surprised. The interviewer looked quite convinced that instance types can be declared in a static class. I am surprised how he was allowed to take the interview in the first place. Or was he checking my confidence?

I wonder.

What are the different types of Asp.Net Session States?

ASP.NET Session State Session state still exists in ASP.NET, partly for backward compatibility, but also as a viable implementation that developers should no longer shy away from. ASP.NET session is free-threaded, but in some cases it can be accessed serially. Session state in ASP.NET still utilizes an HTTP cookie for managing the SessionID, however, ASP.NET also supports storing the SessionID in the URL if using cookies is not desirable. ASP.NET session state also supports two out-of- process modes to simplify deployment in Web server farms: out-of-process state server (StateServer), and out-of-process SQL Server (SQLServer). In-Process Session State ASP.NET defaults to what is known as in-process (InProc) session state. When in this mode, values stored within session state do not require serialization support and are stored within the memory space of the ASP.NET worker process. This behavior is identical to the way ASP stores its session data and has all the same shortcomings and limitations in a Web farm scenario. However, instead of the data being stored in the IIS process, the data is stored in managed memory within the ASP.NET worker process. (When ASP.NET is running on Microsoft Windows 2000, it defaults to the ASP.NET worker process aspnet_wp.exe. However, when ASP.NET is running on Microsoft Windows Server 2003, it will use the new IIS process model w3wp.exe.) When stored in-process, session state data is lost whenever the process is recycled. In Microsoft Windows Server 2003 running IIS 6, the worker process automatically recycles every 29 hours, which is the default setting and is configurable. However, this does mean that every 29 hours the session data will be lost, whether it is 2:00 AM or 3:00 PM. InProc is by far the fastest way to use session state. It doesn’t support Web farm scenarios (unless you enforce client affinity). However, it also doesn’t have the serialization and deserialization overhead associated with out-of-process modes. It’s safe to assume that out-of-process session state is 15–30 percent slower (depending upon variables such as network speed and the size of the object or objects being serialized). Important Use in-process session state (the default) if you have only a single server. In IIS 6, either use out-of-process or disable process recycling behavior to avoid data loss. Code Listing 5-1 shows the configuration settings from machine.config that specify the default settings for session state. Values that apply to InProc appear in bold.

Code Listing 5-1: In-Process Session State Configuration









The timeout value specifies the time, in minutes, after which a session is considered timed out and its values can be removed. Session state uses a sliding expiration: the timeout is reset each time the item is requested. A session could theoretically be kept alive indefinitely if a request was made just once before the value in the timeout is reached. We’ll discuss the cookieless option later in the chapter.

The name of the HTTP cookie used to store the SessionID in ASP.NET is different from the cookie used to store the SessionID in ASP. There is no sharing of session data between ASP and ASP.NET. (See Chapter 11 for more details about migrating session state between ASP and ASP.NET.)

InProc session state allows any data type to be stored, and it participates in the global session events Session_OnStart, which is raised when a new session is created; and Session_OnEnd, which is raised when a session is abandoned. These events can be programmed in either global.asax or within an HTTP module.

Important Don’t use the Session_End event; it can be called only for sessions created in the InProc mode. The event is not raised for sessions created in one of the out-of-process modes when sessions are abandoned.


Although the InProc session is the fastest, in some cases, you might want to trade performance for reliability or ease of management. For example, the out-of-process option is a good choice when you want to support multiple Web servers, or when you want to guarantee that session data can survive the Web server process.

Out-of-Process Session State
ASP.NET session state supports two out-of-process options, state server (StateServer) and SQL Server (SQLServer). Each has its own configuration settings and idiosyncrasies to contend with, such as managing stored types. The ASP.NET State Service is recommended for medium-size Web applications. For enterprise-size or highly-transactional Web applications, SQL Server is recommended.

Important It’s important that the programming model is transparent. For example, we don’t have to change how we access or use session state when we change the storage mode.


We recommend SQLServer for out-of-process session state because it is just as fast as StateServer and SQL Server is excellent at managing data. Furthermore, ASP.NET can communicate with SQL Server natively (meaning internally, using the System.Data.SqlClient libraries), and SQL Server can be configured to support data failover scenarios. In cases in which SQLServer is not available, StateServer works well, but it unfortunately does not support data replication or failover scenarios.

Managing Types for Out-of-Process Modes
If you’re using an out-of-process mode, one of your major costs is the serialization and deserialization of items stored. Using an optimized internal method, ASP.NET performs the serialization and deserialization of certain “basic” types, including numeric types of all sizes, such as Int, Byte, and Decimal, as well as several non-numeric types, such as String, DateTime, TimeSpan, Guid, IntPtr, and UintPtr.

If you have a session variable that is not one of the basic types, ASP.NET will serialize and deserialize it using the BinaryFormatter, which is relatively slower than the internal method. If you’ve created a custom class, and you want to store it in session state, you must mark it with the [Serializable] meta-data attribute or implement the ISerializable interface. ([Serializable] is the C# metadata attribute. is the Microsoft Visual Basic .NET metadata attribute.) The SerializableAttribute class is defined in the mscorlib.dll assembly within the System namespace. The ISerializable interface is defined in the assembly mscorlib.dll and within the System.Runtime.Serialization namespace. When a class is marked with the SerializableAttribute, all public members will attempt to be serialized. If the class contains references to other objects, those objects must also be marked with the SerializableAttribute or implement ISerializable. Implementing ISerializable gives you more control over how the serialization and deserialization of your class takes place. For more details on the serialization of objects in Visual Basic .NET, visit http://www.fawcette.com/reports/vsliveor/2002/09_18_02/hollis/.

For the sake of performance, you’re better off storing all session state data using only one of the basic data types (numeric and non-numeric types) listed earlier. For example, if you want to store a name and address in session state, you can store them using two String session variables, which is the most efficient method; or you can create a class with two String members and store that class object in a session variable, which is more costly.

Important Store only basic data types in session state; avoid storing complex types or custom classes. Storing basic data types will decrease the serialization and deserialization costs associated with out-of-process session as well as reduce the complexity of the system.


Now that you’ve had an overview of out-of-process session, let’s discuss the two out-of-process modes, StateServer and SQLServer.

StateServer Mode
The StateServer out-of-process mode relies on a running Microsoft Windows NT Service as well as changes to the default configuration settings. Code Listing 5-2 shows machine.config with the necessary configuration settings (which appear in boldface) for StateServer. Note that the mode attribute is set to StateServer. The stateConnectionString and stateNetworkTimeout settings are required values for StateServer mode.

Code Listing 5-2: StateServer Session State Configuration









When ASP.NET is configured to use state server for out-of-process session, it uses a TCP/IP address and port number to send HTTP requests to the state server (which is in fact a lightweight Web server running as a Microsoft Windows Service).

The IP address (in stateConnectionString) must be changed to the IP address of the machine running the ASP.NET State Service. The port (the default is 42424), should also be changed unless the state service is running behind a firewall (which it should be). The port number can be configured on the machine running the service by editing the registry and changing the value of the port setting found in the following:

HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\
As seen in Figure 5-1, the default setting for the port is 0x0000A5B8 in hexadecimal, or 42424 in base 10.


Figure 5-1: Changing the default port in the registry












Tip If the server running the state service is accessible outside the firewall, the port address of the state service should be changed to a value other than the default. In version 1.1 of ASP.NET, due to security reasons, only local machines can connect to the state server. To allow only non–local host requests in ASP.NET 1.1, open the same registry entry listed earlier for the port setting: HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\. Change AllowRemoteConnection to 1.


The value of stateNetworkTimeout represents the number of seconds that may elapse between the time ASP.NET tries to connect to the state service and the time the request times out. Although the default value for stateNetworkTimeout does not need to be changed, you have the option to make the value higher or lower depending upon your requirements.

Once the server designated to run the state server has been properly configured, it is simply a matter of starting the Windows service. The service can be started from either the command line or the Microsoft Management Console (MMC) for Services.

Starting the state service from the command line is simple. Navigate to the .NET Framework installation directory. For version 1, this is [system drive]\WINDOWS\Microsoft.NET\Framework\v1.0.3705\. Start the server by executing a net start command:

net start aspnet_state
After starting the service, you should see the following text: “The ASP.NET State Service service is starting. The ASP.NET State Service service was started successfully.”

The second option for starting the state service is through the Services MMC snap-in, which you open by navigating to Start\Administrative Tools\Services. Right-click on the ASP.NET State Service option in the list and select Start to start the service. Once the Services MMC is started, you should see a screen similar to Figure 5-2.



Figure 5-2: Services MMC with ASP.NET state service started













SQL Server Mode
SQL Server is an enterprise-class database solution optimized for managing, storing, and retrieving data quickly and efficiently. It is also capable of replication and clustering. In a clustered environment, SQL Server can be configured to failover. For example, when the clustered production SQL server fails, a backup can take over.

Note that clustered SQL Server scenarios are not supported out of the box for ASP.NET session state. To enable the clustering or replication features of SQL Server, session data must be stored in a non-tempDB table.

Again, you do not need to make any special changes to the code to use SQL Server as the session state store. Code Listing 5-3 shows the necessary configuration file machine.config for SQL Server. (Configuration changes are in boldface code.)

Code Listing 5-3: SQL Server Session State Configuration









The mode attribute needs to be SQLServer, and the sqlConnectionString attribute must point to a server running SQL Server that has already been configured for ASP.NET SQL session state.

Tip For ASP.NET 1, configure SQL Server for mixed-mode authentication by adding the ASPNET account enabled for the necessary SQL Server permissions (EXECUTE) for ASP.NET session state. (The ASPNET account is the user that the ASP.NET worker process runs as.) For ASP.NET 1.1 running on IIS 6, configure SQL Server for mixed-mode authentication by adding the NT AUTHORITY\NETWORK SERVICE account.


If the account has the necessary permissions, integrated authentication should be used. This prevents the need to store a username and password in clear text within the configuration. When integrated authentication is used, ASP.NET accesses SQL Server using the credentials of the Windows user that the worker process runs as. By default, these credentials are ASPNET and NT AUTHORITY\NETWORK SERVICE on Windows Server 2003 running IIS 6.

Important Use integrated authentication rather than store SQL Server credentials within your configuration file. If you decide to use SQL Server user names and passwords, do not use the system administrator (sa) account. Instead use an account that has only the necessary access to the database object required for the operations (for session state, this account is EXECUTE only). If you must use SQL Server credentials, ASP.NET 1.1 supports storing credentials securely.


To configure SQL Server to support ASP.NET session state, either open the InstallSqlState.sql file in isqlw.exe (Microsoft SQL Server Query Analyzer), or use the command-line tool osql.exe. To use SQL Server Query Analyzer, from the Start menu, navigate to \All Programs\Microsoft SQL Server\Query Analyzer. The SQL Query Analyzer application appears in Figure 5-3.


Figure 5-3: SQL Query Analyzer
















Important Ensure SQL Server Agent is running before running the SQL Scripts. The agent runs a periodic job to purge expired sessions from the database.


If you’re running ASP.NET 1, from the toolbar select File | Open [system drive]\WINDOWS\Microsoft.NET\Framework\v1.0.3705\ InstallSqlState.sql. If you’re running ASP.NET 1.1, navigate to [system drive]\WINDOWS\Microsoft.NET\Framework\v1.0.4322\ directory and open the same file. Execute the script, either by clicking the Play button or by pressing F5. Using the command-line tool (osql.exe), open a command window and then navigate to \[system drive]\WINDOWS\Microsoft.NET\Framework\[ASP.NET version]\.

If integrated authentication is enabled for SQL Server and the current Windows logged-on user has permissions to SQL Server, type the following: osql -E < enablesessionstate="">
Another option is to configure session to enableSessionState=“false” as the default setting (you can change this in web.config or machine.config) and use EnableSessionState=“ReadOnly” or EnableSessionState=“true” at the page level. Code Listing 5-4 shows the code for disabling session state.

Code Listing 5-4: Disabling Session State

Important For out-of-process session, set session state to enableSessionState=“false” within the configuration file and set the EnableSessionState page directives to either true or ReadOnly based on what behavior is needed. Note that the length of the session will still be reset (even when set to false).


When you apply this strategy for optimizing out-of-process session, you get fewer requests to the out-of-process session store, which increases the scalability and throughput of the site.

Cookieless Session
Session state, to HTTP purists, is a frowned upon but necessary feature for building real-world Web applications. Session state was designed to work around the limitations of the stateless nature of HTTP. To do so, the browser and the server must share a common piece of data: the SessionID. This shared value must be stored somewhere—we’re certainly not going to ask the user to re-enter an ID value upon each request to the server! To solve this problem, we take advantage of another HTTP feature known as a cookie, which you learned about briefly earlier in the chapter.

A cookie is a highly contentious, much debated feature supported by all browsers that allows the server to store a small amount of data, private to the server, on the client. Upon each client request to the server, the browser sends along any cookie data belonging to that server.

For both ASP and ASP.NET, the SessionID is stored within a cookie. When the client makes requests to the server, the client presents the cookie, giving ASP.NET the opportunity to fetch any associated session data belonging to the presented SessionID.

Important Using the SessionID as a key for user data is not recommended. The SessionID is randomly generated, and session data—as well as session IDs—do expire. Additionally, although a SessionID might be generated on each request, a SessionID is set only when a Session value is set server side. This means that if no session values are set server side, new SessionIDs are issued on each request.


Storing the SessionID in a cookie works very well except when the client chooses not to accept cookies. (By default, cookies are accepted, and the user has to explicitly disable cookie support to avoid using them.) When cookies are not supported, ASP.NET provides a cookieless option in which the SessionID is stored within the URL instead of an HTTP cookie.

An ASP.NET Web application cannot be configured to support both cookie and cookieless SessionID storage; that is, the application cannot dynamically choose whether to use cookies. This can be seen as advantageous because designing an application to accommodate various cookie scenarios can be very difficult.

When building applications to take advantage of a cookieless session, you must carefully design navigation in the user interface. Any links within the site that are not relative (those starting with http://) will cause the user to lose her session when clicked. For relative URLs (for example, /MyStore/default.aspx), the embedded SessionID is automatically added by ASP.NET when generating the page output.

Tip If you have to develop an application that supports both cookie and cookieless sessions, your best strategy is to write an HTTP module to redirect the browser to the appropriate application or server for the supported browser feature, for example, configure a dedicated application that is used for cookieless sessions.

if you use xml formatter to serialize an object, would the private properties be serialized? What happens when you use a binary formatter?

XML Formatter does not serialize private properties. Serialization is the process of storing the state of an object into a persistence storage media and private properties are not serialized. Serialization has nothing to do with Private Properties.

When using Binary formatter, the private properties are serialized. Since it is a binary formatter, it just writes everything it reads from the object into the persistent storage media. Hence the private variables would also be persisted. But logically they should not be and using an XML Formatter is more advisable.

What is an assembly?

An assembly is the primary building block of a .NET Framework application. It is a collection of functionality that is built, versioned, and deployed as a single implementation unit (as one or more files). All managed types and resources are marked either as accessible only within their implementation unit, or as accessible by code outside that unit.

Assemblies are self-describing by means of their manifest, which is an integral part of every assembly. The manifest:

Establishes the assembly identity (in the form of a text name), version, culture, and digital signature (if the assembly is to be shared across applications).
Defines what files (by name and file hash) make up the assembly implementation.
Specifies the types and resources that make up the assembly, including which are exported from the assembly.

Itemizes the compile-time dependencies on other assemblies.
Specifies the set of permissions required for the assembly to run properly.
This information is used at run time to resolve references, enforce version binding policy, and validate the integrity of loaded assemblies. The runtime can determine and locate the assembly for any running object, since every type is loaded in the context of an assembly. Assemblies are also the unit at which code access security permissions are applied. The identity evidence for each assembly is considered separately when determining what permissions to grant the code it contains.
The self-describing nature of assemblies also helps makes zero-impact install and XCOPY deployment feasible.

How can I see what assemblies are installed in the global assembly cache?

The .NET Framework ships with a Windows shell extension for viewing the assembly cache. Navigating to % windir%\assembly with the Windows Explorer activates the viewer.