.NET news » Search results

Visual Studio LightSwitch applications consist of three tiers: presentation, logic and data. This article discusses the logic tier and its save pipeline. The save pipeline is where developers write business logic that runs as changes are processed on the logic tier and saved to the data storage tier. The save pipeline is automatically generated with every LightSwitch application. Understanding the processing done in the save pipeline is not required to successfully build and deploy applications with LightSwitch, but adding save pipeline business logic provides additional flexibility and control when data is saved.

With WebForms, each ASP.NET page's rendered output includes a <form> element that performs a postback to the same page whenever a Button control within the form is clicked, or whenever the user modifies a control whose AutoPostBack property is set to True. This model simplifies web page development, but carries with it some costs - namely, the large amount of data exchanged between the client and the server during a postback. On postback the browser sends the values of all of its form fields (including hidden ones, like view state, which may be quite large) to the server; the server then sends back the entire contents of the web page. While there are some scenarios where this amount of information needs to be exchanged, in many cases the user has performed some action that requires far less information to be exchanged. With a little bit of forethought and code we can have the browser and server exchange much less data, which leads to more responsive web pages and an improved user experience.

Over the past several weeks I've been writing an article series on accessing server-side data from client script. Rather than rely solely on forms and postbacks, many websites use JavaScript code to asynchronously communicate with the server in response to the page loading or some other user action. The server, upon receiving the JavaScript-initiated request, returns just the data needed by the browser, which the browser then seamlessly integrates into the web page. There are a variety of technologies and techniques that can be employed to provide both the needed server- and client-side functionality. Last week's article, Using WCF Services with jQuery and the ASP.NET Ajax Library, explored using the Windows Communication Foundation, or WCF, to serve data from the web server and showed how to consume such a service using both the ASP.NET Ajax Library and jQuery.

In a previous 4Guys article, Creating an Online Boggle Solver, I built an application to find all solutions in a game of Boggle. (Boggle is a word game trademarked by Parker Brothers and Hasbro that involves several players trying to find as many words as they can in a 4x4 grid of letters.) This article takes the lessons learned in Using WCF Services with jQuery and the ASP.NET Ajax Library and uses them to update the user interface for my online Boggle solver, replacing the existing WebForms-based user interface with a more modern and responsive interface. I also used jQuery Templates, a JavaScript-based templating library that is useful for displaying the results from a server-side service.

Bringing the Common Language Runtime (CLR) into SQL Server presents an entirely new set of challenges with regard to privilege and some of the rules that SQL Server developers are used to do not completely translate. Simple grant/deny/revoke logic still applies, but the CLR also brings its own set of specialized permissions, which require slightly different handling in order to properly manipulate.

By not carefully considering these issues when designing your SQLCLR code base, you may be allowing your code too much access.

This article focuses on what the SQLCLR permission sets do to control security and reliability, and what you need to understand when working with them in order to design a system that takes advantage of least privilege. By not carefully considering these issues when designing your SQLCLR code base, you may allow your code too much access, thereby creating potential vectors for security problems down the road..

Chances are, at some point you've tried creating a new user account on a website and were told that the username you selected was already taken. This is especially common on very large websites with millions of members, but can happen on smaller websites with common usernames, such as people's names or popular words or phrases in the lexicon of the online community that frequents the website. If the user registration process is short and sweet, most users won't balk when they are told their desired username has already been taken - they'll just try a new one. But if the user registration process is long, involving several questions and scrolling, it can be frustrating to complete the registration process only to be told you need to return to the top of the page to try a different username.

Many websites use Ajax techniques to check whether a visitor's desired username is available as soon as they enter it (rather than waiting for them to submit the form). This article shows how to implement such a feature in an ASP.NET website using Membership and jQuery. This article includes a demo available for download that implements this behavior in an ASP.NET WebForms application that uses the CreateUserWizard control to register new users. However, the concepts in this article can be applied to ad-hoc user registration pages and ASP.NET MVC.

Read on to learn more!

The appearance of the GridView, DetailsView, and FormView controls can be customized through myriad style-related properties. Properties like CssClass, Font, BorderWidth, BorderStyle, BorderColor, Width, and Height, among others, dictate the general appearance of the rendered control. Properties including HeaderStyle, RowStyle, AlternatingRowStyle, and others allow these same style settings to be applied to particular sections. Likewise, these style settings can be applied at the field level.

In many scenarios, though, the formatting requirements depend upon the value of the displayed data. For example, to draw attention to out of stock products, a report listing product information might set the background color to yellow for those products whose UnitsInStock and UnitsOnOrder fields are both equal to 0. To highlight the more expensive products, we may want to display the prices of those products costing more than $75 in a bold font.

Adjusting the format of the GridView, DetailsView, or FormView based upon the data bound to it can be accomplished in multiple ways. In this tutorial, we'll look at how to accomplish data bound formatting through the use of the DataBound and RowDataBound event handlers. In the next tutorial we'll explore an alternative approach...

A common type of report is the master/detail report, in which the report begins by showing some set of "master" records. The user can then drill down into one of the master records, thereby viewing that master record's "details." Master/detail reports are an ideal choice for visualizing one-to-many relationships, such as a report showing all of the categories and then allowing a user to select a particular category and display its associated products. Additionally, master/detail reports are useful for displaying detailed information from particularly "wide" tables (ones that have a lot of columns). For example, the "master" level of a master/detail report might show just the product name and unit price of the products in the database, and drilling down into a particular product would show the additional product fields (category, supplier, quantity per unit, and so on).

There are many ways with which a master/detail report can be implemented. Over this and the next three tutorials we'll look at a variety of master/detail reports. In this tutorial we'll see how to display the master records in a DropDownList control and the details of the selected list item in a GridView. In particular, this tutorial's master/detail report will list category and product information.

The ASP.NET Web Forms model strives to encapsulate the lower level complexities involved in building a web application. Features like server-side event handlers, the page lifecycle, and view state effectively blur the line between the client and the server, simplify state management, and free the developer from worrying about HTTP, requests and responses, and similar matters. While these facets of the Web Forms model allow for rapid application development and make ASP.NET more accessible to developers with a web application background, their behavior can impact your website's behavior and performance.

View state is perhaps the most important - yet most misunderstood - feature of the Web Forms model. In a nutshell, view state is a technique that automatically persists programmatic changes to the Web controls on a page. By default, this state is serialized into a base-64 encoded string and included as a hidden <input> field in the Web Form. On postback, this state information is returned to the server as part of the POST request, at which point the server can deserialize it and reapply the persisted state to the controls in the control hierarchy. (If this last paragraph made crystal clear sense, great! If not, consider reading my article, Understanding ASP.NET View State, and Dave Reed's article, ViewStateMode in ASP.NET 4, before continuing.)

One potential issue with view state is that it can greatly bloat the size of your web pages. Each new version of ASP.NET seems to include new techniques for managing view state's footprint. ASP.NET 4 adds a new property to all Web controls, ViewStateMode, which allows developers to disable view state for a page by default and then selectively enable it for specific controls. This article reviews existing view state-related properties and then delves into the new ViewStateMode property.

One of the most sure-fire ways to improve a web application's performance is to employ caching. Caching takes some expensive operation and stores its results in a quickly accessible location. ASP.NET version 1.0 introduced two flavors of caching:

• Output Caching - caches the entire rendered markup of an ASP.NET web page or User Control for a specified duration.
• Data Caching - a programmatically-accessible, in-memory data cache for storing objects in the web server's memory.

For a more in-depth discussion on ASP.NET 1.x's caching capabilities, refer to Scott McFarland's Caching with ASP.NET and Steve Smith's ASP.NET Caching: Techniques and Best Practices articles.

In ASP.NET 2.0, the caching system has been extended to include SQL cache dependencies, cache profiles, and post-cache substitution for output cached pages. The Caching for Performance section of the ASP.NET 2.0 QuickStarts provides a good overview of ASP.NET 2.0's caching options. This article explores output caching in ASP.NET 2.0, starting with an overview of output caching and followed by a detailed look at creating pages that include both cached and non-cached markup using fragment caching and post-cache substitution techniques.