Database Access in the Web World

10/18/2009

Accessing a database in a web application is a completely different scenario than accessing a database in a typical client-server desktop application. Most developers hone their database skills in the desktop world and run into serious problems when they try to apply what they have learned with stand-alone applications in the world of the Web. Quite simply, web applications raise two new considerations: problems of scale and problems of state.
Problems of scale are the problems that can result from the massively multiuser nature of the Web. A web application has the potential to be used by hundreds or thousands of simultaneous users. This means it can’t be casual about using server memory or limited resources such as database connections. If you design an application that acquires a database connection and holds it for even a few extra seconds, other users may notice a definite slowdown.  And if you don’t carefully consider database concurrency issues (in other words, what happens when the changes from different users overlap), you can run into significant headaches, such as failed updates and inconsistent data.

Problems of scale can occur when developing traditional client-server desktop applications. The difference is that in most client-server applications they are far less likely to have any negative effect because the typical load (the number of simultaneous users) is dramatically lower. Database practices that might slightly hamper the performance of a client-server application can multiply rapidly and cause significant problems in a web application.

Problems of state are problems that can result from the disconnected nature of the Internet.
As you already know, HTTP is a stateless protocol. When a user requests a page in an
ASP.NET application, the web server processes the code, returns the rendered HTML, and closes the connection immediately. Although users may have the illusion that they are interacting with a continuously running application, they are really just receiving a string of static pages.
Because of the stateless nature of HTTP, web applications need to perform all their work in the space of a single request. The typical approach is to connect to a database, read information, display it, and then close the database connection. This approach runs into difficulties if you want the user to be able to modify the retrieved information. In this scenario, the application requires a certain amount of intelligence in order to be able to identify the original record, build a SQL statement to select it, and update it with the new values.
Fortunately, both ASP.NET and ADO.NET are designed with these challenges in mind. As you work your way through this chapter (and the following two chapters), you’ll learn how to deal with databases safely and efficiently.

Posted in: .NET Framework Website-asp.net Software Programming| Tags: HTTP Database Access Access Web World Web Application Scale problem result from massive nature inconsistent client-server stateless protocol HTML asp.net application

Scenarios and Goals of the Security Application Block

10/18/2009
The Security Application Block is designed to address the most common tasks developers face when they are writing applications that require security functionality. These tasks have been arranged according to scenarios. Each scenario gives an example of a real-world situation, such as authenticating a user; discusses the security functions the situation requires; and shows the code that accomplishes the task. The goal of arranging these tasks according to scenarios is to give the code some context. Instead of showing an isolated group of methods, with no sense of where they can best be used, scenarios provide a setting for the code, putting it in situations familiar to many developers whose applications must use security features. The scenarios are the following:
  • Obtaining a temporary token for an authenticated user
  • Authenticating a user using a token
  • Ending a user session (expire a token)
  • Determining if a user is authorized to perform a task
  For more information about each of these scenarios, see Key Scenarios When to Use the Security Application Block The Security Application Block includes implementations of the following functions:
  • Authorization
  • Security-related caching and session management
  If your applications require the provided implementations, you can use the application block to provide this functionality. However, the application block is also designed to be extensible and includes generic providers for each function. You can adapt the providers to meet your own security requirements.
Note:
If you use the Security Application Block to cache security-related information, the default caching store provider for the security cache is the Caching Application Block. Although the Caching Application Block can be configured to encrypt cache data in backing stores, the application block does not support encryption of cache data stored in memory. If an attacker compromises the computer and accesses the memory of your process, he or she can access information stored in the cache. If this threat is significant for your application, you should avoid storing sensitive information such as credit card numbers or passwords in the cache or use an alternate caching store provider that supports in-memory encryption.
Posted in: .NET Framework MS Windows Software Programming| Tags: Best Practice .NET asp.net Enterprise Library Application Validation Application Block C# Benefit

Understanding Important Windows PowerShell Concepts

07/25/2009

The Windows PowerShell design integrates concepts from many different environments. Several of them are familiar to people with experience in specific shells or programming environments, but very few people will know about all of them. Looking at some of these concepts provides a useful overview of the shell.

Commands are not Text-based

Unlike traditional command-line interface commands, Windows PowerShell cmdlets are designed to deal with objects - structured information that is more than just a string of characters appearing on the screen. Command output always carries along extra information that you can use if you need it. We will discuss this topic in depth in this document.

If you have used text-processing tools to process command-line data in the past, you will find that they behave differently if you try to use them in Windows PowerShell. In most cases, you do not need text-processing tools to extract specific information. You can access portions of the data directly by using standard Windows PowerShell object manipulation commands.

The Command Family is Extensible

Interfaces such as Cmd.exe do not provide a way for you to directly extend the built-in command set. You can create external command-line tools that run in Cmd.exe, but these external tools do not have services, such as help integration, and Cmd.exe does not automatically know that they are valid commands.

The native binary commands in Windows PowerShell, known as cmdlets (pronounced command-lets), can be augmented by cmdlets that you create and that you add to Windows PowerShell by using snap-ins. Windows PowerShell snap-ins are compiled, just like binary tools in any other interface. You can use them to add Windows PowerShell providers to the shell, as well as new cmdlets.

Because of the special nature of the Windows PowerShell internal commands, we will refer to them as cmdlets.

Note:

Windows PowerShell can run commands other than cmdlets. We will not be discussing them in detail in the Windows PowerShell Primer, but they are useful to know about as categories of command types. Windows PowerShell supports scripts that are analogous to UNIX shell scripts and Cmd.exe batch files, but have a .ps1 file name extension. Windows PowerShell also allows you to create internal functions that can be used directly in the interface or in scripts.

Posted in: .NET Framework Software Programming| Tags: PowerShell Concept Command Text-based Extensible Integrate Environment Familiar Cmdlets PS

.NET Windows Forms Interview Questions and Answers

07/11/2009
  1. Write a simple Windows Forms MessageBox statement.
    System.Windows.Forms.MessageBox.Show
    ("Hello, Windows Forms");
  2. Can you write a class without specifying namespace? Which namespace does it belong to by default??
    Yes, you can, then the class belongs to global namespace which has no name. For commercial products, naturally, you wouldn’t want global namespace.
  3. You are designing a GUI application with a window and several widgets on it. The user then resizes the app window and sees a lot of grey space, while the widgets stay in place. What’s the problem? One should use anchoring for correct resizing. Otherwise the default property of a widget on a form is top-left, so it stays at the same location when resized.
  4. How can you save the desired properties of Windows Forms application? .config files in .NET are supported through the API to allow storing and retrieving information. They are nothing more than simple XML files, sort of like what .ini files were before for Win32 apps.
  5. So how do you retrieve the customized properties of a .NET application from XML .config file? Initialize an instance of AppSettingsReader class. Call the GetValue method of AppSettingsReader class, passing in the name of the property and the type expected. Assign the result to the appropriate variable.
  6. Can you automate this process? In Visual Studio yes, use Dynamic Properties for automatic .config creation, storage and retrieval.
  7. My progress bar freezes up and dialog window shows blank, when an intensive background process takes over. Yes, you should’ve multi-threaded your GUI, with taskbar and main form being one thread, and the background process being the other.
  8. What’s the safest way to deploy a Windows Forms app? Web deployment: the user always downloads the latest version of the code; the program runs within security sandbox, properly written app will not require additional security privileges.
  9. Why is it not a good idea to insert code into InitializeComponent method when working with Visual Studio? The designer will likely throw it away; most of the code inside InitializeComponent is auto-generated.
  10. What’s the difference between WindowsDefaultLocation and WindowsDefaultBounds? WindowsDefaultLocation tells the form to start up at a location selected by OS, but with internally specified size. WindowsDefaultBounds delegates both size and starting position choices to the OS.
  11. What’s the difference between Move and LocationChanged? Resize and SizeChanged? Both methods do the same, Move and Resize are the names adopted from VB to ease migration to C#.
  12. How would you create a non-rectangular window, let’s say an ellipse? Create a rectangular form, set the TransparencyKey property to the same value as BackColor, which will effectively make the background of the form transparent. Then set the FormBorderStyle to FormBorderStyle.None, which will remove the contour and contents of the form.
  13. How do you create a separator in the Menu Designer? A hyphen ‘-’ would do it. Also, an ampersand ‘&\’ would underline the next letter.
  14. How’s anchoring different from docking? Anchoring treats the component as having the absolute size and adjusts its location relative to the parent form. Docking treats the component location as absolute and disregards the component size. So if a status bar must always be at the bottom no matter what, use docking. If a button should be on the top right, but change its position with the form being resized, use anchoring.
Posted in: .NET Framework| Tags: .NET Questions Answers Windows Form WinForm MessageBox ProgressBar TextBox

Hot Posts

Latest posts

Tags

Others

Sponsors