Introduction to the Validation Application Block
This topic includes a series of brief sections that provide information to help you decide whether the Validation Application Block is suitable for your requirements. This topic includes the following sections:
- Common Scenarios
- Example Application Code
- Highlights of the Validation Application Block
- Determining When to Use the Validation Application Block
- Alternatives to Using the Validation Application Block
In addition to this introductory material, the documentation contains the following topics:
- Developing Applications Using the Validation Application Block. This topic explains how to include the Validation Application Block in your applications and how to configure it. It also contains more detailed information, such as how to create custom message templates and information on how validation works with inheritance.
- Key Scenarios. This topic shows different ways to use the Validation Application Block in your own applications.
- Design of the Validation Application Block. This topic includes a class diagram of the Validation Application Block.
- Extending and Modifying the Validation Application Block. This topic explains how to extend the application block by adding custom validators and attributes. It also contains advice about how to modify the source code.
- Deployment and Operations. This topic explains how to deploy and update the application block assemblies. It also explains the application block's instrumentation.
- Validation QuickStarts. This topic explains how to install and configure the two QuickStart applications and contains a series of walkthroughs that demonstrate how to incorporate common validation operations into an application.
For details of the system requirements for the Validation Application Block, see System Requirements. For details of the dependencies for the Validation Application Block, see Application Block Dependencies.
Common Scenarios
Validation has many applications. For example, you can use it to prevent the injection of malicious data by checking to see if a string is too long or if it contains illegal characters. You can also use validation to enforce business rules and to provide responses to user input. It is often important to validate data several times within the same application. For example, you may need to validate data at the UI layer to give immediate feedback when a user enters an invalid data value, and again at the service interface layer for security.
The Validation Application Block is designed to address the most common tasks developers face when they must validate input either from a user or another system. These tasks are arranged according to scenarios. Each scenario gives an example of a typical way to use the Validation Application Block and shows the code that accomplishes the task.
The scenarios are the following:
- Using Attributes to Define Validation Rule Sets
- Using Self Validation
- Validating Objects
- Integrating with ASP.NET, Windows Forms, and WCF; this scenario includes information about integrating the Validation Application Block into the following types of applications:
- ASP.NET
- Windows Forms
- WCF
Highlights of the Validation Application Block
The Validation Application Block has the following benefits:
- It helps maintain consistent validation practices.
- It includes validators for validating most standard .NET data types.
- It allows you to create validation rules with configuration, attributes, and code.
- It allows you to associate multiple rule sets with the same class and with members of that class.
- It allows you to apply one or more rule sets when you validate an object.
- It can be integrated with ASP.NET, Windows Forms, and Windows Communications Foundation (WCF).
Determining When to Use the Validation Application Block
The Validation Application Block allows you to encapsulate validation best practices into easily maintainable code that you can reuse. Encapsulation also allows you to separate the application code from the validation logic. In some situations, you may be able to update the validation logic without redeploying the application. Another common situation where the application block works well is when your validation code must work across multiple layers of the application's architecture.
In very simple cases, when you only need to validate a few objects, you may not want to incur the overhead of adding the application block.
Alternatives to Using the Validation Application Block
Alternatives to using the Validation Application Block may include using the validation capabilities that are a part of ASP.NET and Windows Forms. Another alternative for WCF and other applications that use XML data is to use the XML Schema Definition tool (XSD), which allows you to validate messages at the XML level. If your validation logic only needs to be applied within these technologies you may not need to use the application block. However, if the validation logic needs to be reused, the application block is a better choice.
Posted in: .NET Framework| Tags: WCF Introduction Validation Application Block ValidationASP.NET 4.0 AJAX Preview 4
The preview contains the following new features:
- ADO.NET Data Services support
- WCF and ASMX Web service integration
- ASP.NET AJAX Client Templates
- Declarative instantiation of client-side controls and behaviors
- Observable pattern for plain JavaScript objects
- Live Bindings
- Markup Extensions
- DataView control and DataContext component
- Command Bubbling
- Change tracking and identity management
- Support for managing complex links and associations between entities from multiple entity sets or tables
- Extension methods allowing change tracking and read-write client-server scenarios using other JSON services, including RESTful or JSONP based services
Download: ASP.NET AJAX 4.0 Preview 4
Note: To use the new features in a Web page, you must first enable the updated version of Microsoft Ajax on the page.See the Asp.Net Ajax Preview 4 Readme for details.
New with this release:
- Full Client Reference documentation
- A set of Code Samples using ASP.NET AJAX templates
The last update to the samples was on March 23rd 2009. Posted in: Website-asp.net| Tags: WCF asp.net ajax Preview ado.net
A Guide to Designing and Building RESTful Web Services with WCF 3.5
Overview
From the point of view of REST, a “real” Web service is a service designed to embrace the “Web” from the ground up. The Web has become the most successful distributed computing platform ever developed, thanks to years of investment and widespread usage. The Web platform includes concepts that you’re probably already familiar with like URIs, HTTP, and common data formats like XML, RSS/ATOM, and JSON. Ultimately, services that embrace these core concepts will immediately derive the valuable benefits they provide.
REST defines an architectural style based on a set of constraints for building things the “Web” way. REST is not tied to any particular technology or platform – it’s simply a way to design things to work like the Web. People often refer to services that follow this philosophy as “RESTful services.” In this whitepaper, we’ll cover the fundamental REST design principles and show you how to build RESTful services with Windows Communication Foundation (WCF), the WCF REST Starter Kit, and ADO.NET Data Services.
The Web Platform
Before immersing ourselves in the world of REST, we should review the essence of the Web platform as we know it today. We call it the “Web” because the architecture provides a framework for creating and navigating a Web of resources. A resource could be anything. Some resources are simply data like files, images, or videos while others are temporal services that produce dynamic output (e.g., Pluralsight’s upcoming course schedule). Some services even run complex algorithms behind the scenes. You can think of the Web as a resource-oriented architecture for building large-scale distributed systems.
Resource-Oriented Architecture
On the Web, every resource is given a unique identifier, also known as a universal resource identifier (URI). The most common type of URI used on the Web today is a uniform resource locator (URL). As an example, the URL – http://www.pluralsight.com/main/ilt/schedule.aspx – identifies and locates Pluralsight’s upcoming training course schedule, a popular resource made available on our site.
Since a given URI uniquely identifies a resource, it can be saved for future use and shared with others. For example, when you find a resource you want to get back to later, you can: try to remember it, write it down on a napkin, save it to disk (as a browser bookmark), or store it in a database of bookmarks on the Web, in which case the bookmark itself becomes a new Web resource. You can also share the resource with others by telling them the URI or emailing it to them so they can easily browse to it themselves. Many companies try hard to create easy-to-remember URIs that can be successfully conveyed via advertising and will hopefully spread via word-of-mouth. In the end, as long as you have the URI, you can enter it into a Web browser and retrieve the resource at some future point in time.
Now, the reason it’s called the “Web” is because resources can contain hyperlinks to other resources, thereby creating a Web of resources. Hyperlinks make it possible to navigate from one resource to another by using the target resource URI. For example, in HTML you link to another resource through the anchor element. When a browser renders an anchor element, it provides a visual cue showing that you can click on the anchor text to issue a GET request for the target resource URI. Humans play an important role in most Web applications because they’re the ones viewing the page, entering data in forms, and clicking links. Humans are really the client-side engine navigating the Web of resources.
When you retrieve a resource using a Web browser, you’re really retrieving a representation of that resource. This implies that there could be multiple representations of a particular resource. There are many standard and common formats used on the Web today to represent resources that virtually all browsers understand. One of the most common formats is (X)HTML but others are common as well, including JPEG and GIF, WMV and SWF, RSS and ATOM, CSS and JavaScript/JSON to name a few. When a browser receives one of these representations, it does its best to render it for human viewing.
Fundamental HTTP Concepts
The Web platform also comes with a standard communication protocol – HTTP – for interacting with resources and their representations. HTTP defines a standard set of methods, status codes, and headers for interacting with resources on the Web. Figure 1 describes the most commonly used HTTP methods, their semantics, and whether they’re defined to be safe and idempotent .
The GET method allows you to retrieve a resource representation, while PUT allows you to create or update a resource with the supplied representation, and DELETE allows you to delete a resource. In short, GET, PUT, and DELETE provide basic CRUD operations (create, retrieve, update, and delete) for the Web. HEAD and OPTIONS, on the other hand, provide the ability to retrieve resource metadata, allowing you to discover out how to interact with resources at run time.
Say we have a resource representing a course description at Pluralsight. You’d issue a GET request to retrieve the course description from a particular URI. If you wanted to update the course description with some changes, you’d issue a PUT request to the same URI supplying the modified course description. If you PUT the course description to a new URI, you’d effectively be creating a new course description resource. And, of course, you’d delete a course description by issuing a DELETE request.
Posted in: WCF Topic| Tags: WCF HTTP REST Web Service RESTful Guide