Asp.Net Dynamic Data – StringLengthAttribute

The name of this attribute says it all – it allows you to specify the maximum length of a string and Its signature is almost the same as the RequiredAttribute

StringLength(“Maximum Length”“Error Message”, “Error Resource”, “Error Resource Type”)

The only issue is that when you set this attribute it sets the text box max length which means that it is impossible for the user to exceed the maximum you set so any error message will never be displayed!

However, this is the same behaviour that Dynamic Data does by default based on the table definition, so the attributes real use is either when you want to restrict the length of a string so that its shorter than the database allows, or if using Entity Framework and you create your own entity you can limit the length of data entered using the standard dynamic data functionality.

As per always to use simply decorate the property with the attribute

[StringLength(15)]

public object City { get; set;}

The user won’t actually see anything they just won’t be able to enter any text longer than the length you’ve set.
CodeProject

Asp.Net Dynamic Data – RequiredAttribute

The RequiredAttribute overrides the model to allow you to specify a nullable field has to be completed.

Its constructor allows you to specify the error message you want to display instead of the standard error message:

Required(“Error Message”, “Error Resource”, “Error Resource Type”)

Just decorate the property with the attribute as per below:

[Required(ErrorMessage = "You must enter a phone number"))]]

public object Phone { get; set;}

And the user will then see:

Simple.

CodeProject

MS Ajax Library under threat?

Just been reading a post by Stephen Walter about Scott Guthrie announcing Microsoft is putting its weight behind jQuery as the defacto client side technology for Microsoft products.

The post expands on what MS are doing and specifically putting resources into templating within jQuery.  Up to now the Ajax Library has been the way that MS have ‘suggested’ you do client side data binding but with their adoption of jQuery is the Ajax Library under threat?

As the amount of functionality in jQuery increases why should developers continue to use the MS Ajax Library? Especially if it seems another technology with more widespread acceptance appears to be coming along to replace it?

Will the MS Ajax Library go the way of Linq-To-Sql where MS support it but developing it is not a priority?

I for one will not be spending my time looking at the MS Ajax Library unless I need to for an existing project, my own spare time will go towards increasing my jQuery knowledge.

Asp.Net Dynamic Data – RegularExpressionAttribute

As you would expect this attribute allows you to apply validation to a field in the form of a regular expression, if the data entered doesn’t match the expression it isn’t valid.

RegularExpression(“Pattern”, “Error Message”, “Error Resource”, “Error Resource Type”)

The expression will be evaluated against the field value when the user attempts to insert or update the data and if it doesn’t match then the error message will be displayed.  Just like the Range attribute you are able to specify either specific text or a resource for an error message.

Simply decorate the field with the attribute as per usual:

[RegularExpression(@"^\d{1,7}$",

ErrorMessage = "Quantity must be a whole positive number.")]

public object Quantity { get; set; }

And then when a user tries to put text in the field they will see:

CodeProject

Asp.Net Dynamic Data – RangeAttribute

The range attribute allows you to specify that a specific field should only be able to accept a certain range of values.

By default the RangeAttribute will work with Int32 or Double values but it is possible to specify your own type and then define the max and min values as strings this then provides the ability to do things like date range checking.

For Int32 and Double the constructor looks like this:

Range(“Minimum Value”, “Maximum Value”, “Error Message”, “Error Resource”, “Error Resource Type”)

For the custom type the constructor looks like this:

Range(“Type”, “Minimum Value”, “Maximum Value”, “Error Message”, “Error Resource”, “Error Resource Type”)

We can see that Range shares similarities with the DataType attribute that I covered previously so if the field being validated fails validation you can either specify a string or message or use a resource for the error message to be displayed.

So to use it you simply decorate your meta class with the attribute on the field you want validated

[Range(1,100,ErrorMessage ="Value must be between 1 and 100")]

public object Quantity { get; set; }

Which then ends up being displayed on the site as:

CodeProject

Asp.Net Dynamic Data – Validation Attributes

I’m leaving my musings on Linq-to-Sql for a moment and returning to dynamic data to cover off the validation attributes.

The table below lists the available attributes;

Attribute	Description
RangeAttribute	Specifies the numeric range constraints for the value of a data field in Dynamic Data.
RegularExpressionAttribute	Specifies that a data field value in ASP.NET Dynamic Data must match the specified regular expression.
RequiredAttribute	Specifies that a data field value is required.
StringLengthAttribute	Specifies the maximum length of characters that are allowed in a data field.

To use these attributes you use them on a meta data class just like you do for the display attributes.

Over the next few posts I’m going to detail each of these attributes.

CodeProject

Linq-to-sql to use or not to use

Following on from my previous post I mentioned the problems encountered trying to use an ORM for the first time, specifically linq-to-sql.

In the recent project where my team used Linq-to-sql (L2S) we were using Asp.Net Dynamic Data and we ended up with lots of data access in the code behind.  I plan to cover our experience of using Dynamic Data in an application in a future post but let me say now its not what I expected – and not in a good way.

So the team moved onto another project and we wanted to be able to put a proper layered design in place with a presentation, business logic and data access layers and immediately ran into a problem in that if we wanted to create an app that conformed to good design principles e.g. Dependency Inversion Principle, then we were going to run into a few issues.

Now I know that I’m way behind the curve on the use of L2S as most of the blog posts and articles I’ve been reading are from back in 2007, but I have been having a bit of difficulty finding information about using L2S in a layered and tiered system which worries me since it may be a case of “it doesn’t do it but you can make it do it” which is a code smell to me.

So far I’ve found a few articles and the one thing that strikes me is the amount of additional work that is required to make L2S work in a layered way, I know that it doesn’t support POCO but at the same time simply using it as an ORM seems to be more difficult than I would have hoped.

The following articles are a good summary of the information I’ve found and I’m still looking into this to see what I can find.

Using the IRepository pattern with Linq-to-SQL
Linq to Sql – How-to Separate the entities and the DataContext.
LINQ to SQL Queries out of a Business Layer