Mike Christensen: Web Dev Guy : .NET Programming

Castle ActiveRecord

mikechr — Tue, 18 Mar 2008 10:07:00 GMT

Lately, I’ve been playing around with Castle ActiveRecord tolearn about this particular technology. For those of you who are unaware, Castle ActiveRecord is an open sourceimplementation of the ActiveRecord pattern written in .NET and built onNHibernate.

The ActiveRecord pattern represents rows in a table asinstances of a class (with column values as instance methods) while providingaccess to the table itself as static methods of the class.

For example, a database table named Users might berepresented by a class called User. The User class would have a static method called FindRow which takes ina numeric value corresponding to the primary key of that table. User.FindRow(5) would return aninstance of a User object, which would have various properties such as Name.

The benefit of this is it allows developers to access andmanipulate data in a database while providing a layer of abstraction from theactual database syntax. This codecan be database agnostic and hide the user from SQL queries and what not. It also allows simplifying databasecode and being able to perform basic database operations in one or two lines ofcode.

One of the benefits of Castle ActiveRecord is you can defineyour entire database schema using .NET code and even have the engine create thedatabase for you. For example, tocreate a User table, we could use the following code:

[ActiveRecord(“Users”)]

public class User : ActiveRecordBase<User>

{

string name;

[Property(NotNull = true)]

public string Name {get {return name;} set {name = value;}}

}

Using various attributes, you can specify database typemappings, primary keys, foreign constraints, indexes, etc. When you’re done, you can instructActiveRecord to create the database using a given connection string.

We can now create a row in this table with the followingcode:

User user = new User();

user.Name = “Mike”;

user.Create();

This eliminates the need to use ADO.NET or construct SQLstatements or stored procedure calls.

One interesting thing you can do is specify the relationsbetween tables. If I had an Ordertable, I can specify a User that placed the order:

Public class Order

{

….

[BelongsTo(“Name”, NotNull = true)]

public User PlacedBy {get {return _placedby;}}

You’ll notice this method actually returns a User object, notjust an int or a guid or what not. When an Order row is queried, Castle ActiveRecord joins in the Userstable and also populates the PlacedBy instance of the order. You can enable a feature called “lazyloading” which will not query the Users table until the property getter isaccessed. This would prevent thegeneration of queries with lots of joins.

So far, I’ve found Castle ActiveRecord to do a great jobhandling simple database operations for me, however it definitely has itsdrawbacks. I’ve found it lackingin creating any sort of complicated database schema, as it doesn’t seem to beable to create indexes on foreign keys or allow the user to specify clusteredvs non-clustered indexes. However,it can also generate a SQL script to create your database and output to a fileso you can make changes before provisioning your database. For more complicated scenarios, I wouldnot use Castle ActiveRecord for database provisioning.

There were a few instances where I wanted to be able toreturn only certain columns from the database and control exactly what tablesget join’ed in. It seems CastleActiveRecord wants to return all columns all the time, or no columns and generate new SELECTstatements every time you access a property. It would be nice if we could simply specify what columns wewant to query for, and the remaining properties would remain null. For these scenarios, CastleActiveRecord can create an IDbCommand and you can fire off your own storedprocedure or SQL statement. I’vefound using a mix of regular ADO.NET and ActiveRecord calls for the simplerstuff is a great approach for more complicated applications. The ActiveRecord base class also allows you to override various methods, and pretty much any part of the system can be rewritten.

One thing that has disappointed me is it seems support fortransactions is completely broken! I can create a transaction like so:

using(TransactionScope t = new TransactionScope())

{

//Do some DB calls

t.VoteCommit();

}

In theory, if the code crashes, the transaction will neverbe committed and the Dispose method of TransactionScope will roll thetransaction back. However, when Itried this, I found the SQL code isn’t getting run and no SQL errors would begenerated until the Transaction is disposed, thus making it impossible to rollback the transaction due to database errors. On thesupport forums, I found several other people who ran into this problem but noone had a solution for it yet.

Overall, I think this technology is a great model for dataaccess using .NET applications and works perfectly for web applications aswell. It seems they need to ironout a few minor problems, but they have a large following and an active supportcommunity. It’s also open sourcewith a very flexible license, which would allow large applications to run ontheir own customized version of Castle ActiveRecord. I think the pattern is very solid and at the very least,should give you some ideas for creating a database access layer from scratch for yourweb based applications. I’d bevery interested in hearing from anyone using Castle ActiveRecord in theirapplications and what they like and don’t like about it.

For more information, visit: http://www.castleproject.org/activerecord/index.html

Mike

Writing a simple managed control under IE

mikechr — Tue, 28 Nov 2006 13:12:00 GMT

Most web developers are aware of various "controls" and "applets" that can be "hosted" by "Internet Explorer" (hmm, not sure why I quoted that last thing, I guess I was on a "roll".) This code is compiled code that runs within the IE process and draws itself within the boundaries of the document. The control even has access to the outside container. This is useful for doing all sorts of nifty stuff that might be hard to do using pure script or HTML, such as drawing graphs, animation, creating an interactive grid, creating a chat room, etc. Most of these controls are written in Java or COM (ActiveX). Java requires a special runtime that you have to download, and ActiveX requires your users to be running one of the many ActiveX compatible web browsers (There's tons! IE3.. Umm, IE4.. IE5.. Oh yea, IE5.5.. IE6, just to name a few).. However, what if you really want to keep users away from your site and write a control that requires them to download a special runtime ANNNNND only be able to use one browser. Well, then my friend you definitely need to write your own managed controls.

Only a hand full of web developers are aware that IE (recent versions, not sure which ones) can run managed code. Even less than a hand full (maybe a paw of a very small cat?) can actually tell you how to do this. Provided your users have the .NET framework installed (who doesn't?) there's a special syntax of the <object> tag that can instantiate a managed Winforms control. I found information on the Internet a little sparse on this subject so I decided to write a post describing exactly how to do this. Not that you should, as I'm sure I'll get 32,768 comments telling me that my apps are crap, proprietary and how that mentality somehow mirrors the exact attitude of Microsoft as a whole. Well, let me tell you something. This blog is dedicated to building web based applications, not web pages. Applications run on a certain platform. That platform might be Windows, that platform might be Mac, that platform might be the Java runtime. It might be a Commodore PET, a cell phone, a Zune, one of those old TI-85 graphing calculators, whatever. This platform can also be Internet Explorer. In fact, one of the reasons IE became so much more popular (especially within corporate networks) over say, Netscape, is it's an actual web application platform - not just a browser. Authors of applications can write applications for whatever platform they choose, based on its requirements as well as the users of said application. I might write an IE specific application for setting up direct deposit because my IT department has rolled out IE to everyone in my company. It's cost effective to target a single platform. There exists a certain spectrum; on one side you can scale to many different types of users but your development/test costs go way up and/or your feature set goes way down. On the other side, you can write a program once for a certain platform and target a very specific set of users. It's up to developers to figure out the best spot in that spectrum for their specific application. So enough of my rant, let's get back to the subject.

First, let's create a managed DLL with a single class in it. Since I don't feel like writing a full fledged control, all this thing will do is pop up a message box. Or maybe I don't actually know how to program and this whole blog's a lie. However, you'll get the point - you can add more controls to the child controls collection, override all sorts of events, etc.

[assembly:System.Security.AllowPartiallyTrustedCallersAttribute]
namespace HostedControlTest {
   public class TestControl : Control
   {
      public TestControl()
      {
         MessageBox.Show("Hello World!");
      }
   }
}

Compile the DLL, upload it to your web server in a location that clients have access to reach. You can test this by typing in the URL for the DLL and make sure the IE "Save" dialog comes up and you can download your own DLL. You might have certain web server security restrictions (especially if it's a Sharepoint server) that prevent users from downloading DLL files. It doesn't matter what web server you're using, it doesn't matter if the web server knows anything about .NET. It's simply a binary file sitting up on a server somewhere and it's downloaded exactly how, say, a JPG file is downloaded. Also, I'm pretty sure you can even use another extension other than DLL.

Once you have this working, create a new web page. On the page, place an object tag that looks something like:

You can replace HostedControlTest.dll with any valid relative path to your DLL. After the pound sign (or, octothorpe as I like to say) is the class within the DLL to load. Note I fully qualify the path with the namespace as well.

Load up your page through your web browser and the control should run and you should get a popup on your screen. No need to sign anything, no need to click "Yes" to any security warnings, etc. In fact, all security is taken care of for you by Code Access Security and is enforced by the runtime's security policy on your machine. Your control can request permissions (such as local file access) and it's up to the client's machine what it trusts the control to do. If a control all of a sudden tries to do something evil, the runtime will throw an exception.

That's all there is to it. Don't ask me any questions because this is all I know! Seriously. Actually, feel free to ask me questions and I'm sure I can find out the answers for you. Thanks!

Mike (Web Dev Guy)

More about type descriptors

mikechr — Wed, 31 May 2006 02:18:00 GMT

The other day, one of my readers posed a question regarding my recent post “Data Binding to Custom Objects” – The question was essentially “Why are you writing all this code? There’s much simpler ways to do the same thing.” Well, the reader is correct. There are many ways to do this same thing. We’ll go over that in a second. First, let me take a shot at defending myself. All over the web, there’s thousands of web sites and articles, blogs and newsgroups, discussion lists and bulletin boards all about “how to do stuff in .NET.” This is great, and it helps you find the information you’re looking for to solve the problem that you currently have in front of you in your day to day jobs. However, the truly great programmers are the ones who know what’s going on behind the scenes. Managed languages such as Java, VB and C# get a lot of criticism from the more “pure programmers” who prefer to work more low level with C and assembly. Some claim there’s an entire generation of programmers who will never write their own memory manager, never create a linked list class from scratch, don’t know how a hash table works internally, don’t know how pointers really work, and don’t know the difference between memory allocated on the stack and memory allocated on the heap. I would disagree and say that it’s not the language itself that’s directly responsible for this new “generation” of programmers, but the complexity of the APIs they depend on. If you took the .NET framework out of C#, you’d have nothing more than a object-oriented language that still relies on the developer to construct these sorts of collection objects and design algorithms. This is no different than the plethora of ready made objects MFC provides for C++ Windows programmers. A language is simply an abstract way of expressing an idea, but those more familiar with the internal workings of a language will be the ones who can exact their ideas in a clear and more precise manner. Just because the .NET framework comes with a Hashtable class doesn’t mean you shouldn’t know how to write your own, and just because the .NET framework can take care of property descriptors for you doesn’t mean you shouldn’t learn how they work.

This new generation is not because of lazy programmers, or programmers who didn’t learn the basics. Programmers in general will learn what they need to do their job, and no matter how low level you get, there’s always a level of abstraction. Assembly programmers said this about C, C programmers said this about VB. Until you want to write everything in pure machine code, running in ring 0, on your own CPU design that you soldered together in your basement, you’re relying on a framework that makes your job easier. What’s to blame is this concept of “rapid application design” which VB started. It became critical to toss together these quick little applications in a fraction of the time it would take with more low level languages. IDEs started doing the boring work for you, which is great as long as you know what’s going on. Which leads me back to my original point – there’s plenty of places on the net to find out how to do something, this blog is dedicated to explaining how things works underneath. There’s only so far you will get memorizing what APIs to use where, but I promise you it’s always worth the time to really dig into something and learn what’s going on, for when you need to modify how something behaves or figure out how to fine tune something, you’ll have a pretty good idea of how to do that.

So use my article as a learning tool, this is how the data binding code works internally and this is how ADO.NET works inside. Now, if you’re simply wanting to bind a collection of simple objects to a grid, you can rely on “default type descriptors” rather than generating your own custom type descriptor as described in my article.

Take the following class:

class Company

{

private string _name;

private string _address;

public string Name { get { return _name; } }

public string Address { get { return _address; } }

public Company(string name, string address)

{

_name = name;

_address = address;

}

It couldn’t be simpler, it has two string properties and a constructor. I can bind it to the Data Grid like so:

protected void Page_Load(object sender, EventArgs e)

{

List<Company> list = new List<Company>();

list.Add(new Company("Microsoft", "123 Main"));

list.Add(new Company("IBM", "333 Main"));

Grid.DataSource = list;

Grid.DataBind();

}

My grid doesn’t change, it still binds to the “Name” and “Address” property of the object. Internally, the grid still asks List<> for an enumerator, which List<> provides. Each “Company” object in the list doesn’t provide a custom type descriptor, so a default type descriptor is used. This type descriptor will look for a public method matching the names of the bound fields. Note this must be a method, not a property (if I mark _name public and bind to that, I’d get a runtime error.) This works great for the simple case, but those who used this method without first writing their own custom type descriptor would have no idea why this works, or how they can manipulate or extend this system to do exactly what they wanted. Suppose later on, I wanted to provide some dynamic array of properties, such as items created by the user, or retrieved from a database. I’d be totally lost and never know how to create my own custom type descriptors. Hopefully some people out there got some use from my post, and there will be some better, more efficient code out there because of my efforts.

Thanks for the comments,

Mike Christensen – Web Dev Guy

Data Binding to Custom Objects

mikechr — Thu, 18 May 2006 09:18:00 GMT

I’m back!

I apologize for my lack of recent blogging, but this post should help make up for that. We’ll be discussing data binding to custom collection objects. After reading my blog on building your own data bound controls, you’ll know that I like to stress the importance of avoiding unnecessary conversions between one data format to another. It’s completely unnecessary to create a DataSet object simply to bind it to a grid control unless your data was already in the form of a DataSet in the first place (for example, retrieved through ADO.) If you’re building your own collection classes anyway, you might as well make them expose the proper interfaces to be bindable. Once you do that, you can simply set them directly to the DataSource property of any .NET control and you’re set.

So how does one make their collection class into a source for data binding? If you haven’t yet read my blog on building your own data bound controls, I suggest you stop now and read that first. It will explain how data bound controls work and how they actually access the data in objects they’re data bound to. You’ll then have a pretty good idea of how these controls work internally and what they would expect from any custom data source object.

To recap, data bound controls such as the DataGrid and GridView controls expect data sources to be Enumerable. This means they implement IEnumerable or IEnumerable<T> (in .NET 2.0.) Not only that, each item in this enumerable list is expected to support property descriptors (usually by implementing ICustomTypeDescriptor.) In the .NET framework, you can find a few examples of objects that implement ICustomTypeDescriptor such as DataRowView. One can see how this fits in, a DataTable exposes an enumerable list (the Rows object) that expose a collection of DataRowView objects which implement ICustomTypeDescriptor. When you bind to a column in this table, the grid accesses the value of each column by calling GetProperty on the type descriptor. The grid knows nothing about DataViews or ADO data types, but type descriptors allow you to look up a property of an object using a string.

So let’s get to work. First off, I’ll be using the new GridView ASP.NET control because it’s new and cool, but you can use any control that supports data binding since they all work the same. My web page will display a list of high tech companies and provide a full mailing address. So here’s my web page:

<body>

<div>

<center>High-Tech Company Phone Book</center><br />

<asp:GridView runat="Server" ID="Grid" AutoGenerateColumns="false">

<asp:BoundField HeaderText="Name" DataField="Name" />

<asp:BoundField HeaderText="Address" DataField="Address" />

<asp:BoundField HeaderText="City" DataField="City" />

<asp:BoundField HeaderText="State" DataField="State" />

<asp:BoundField HeaderText="Zip" DataField="Zip" />

</Columns>

</asp:GridView>

</div>

</form>

</body>

</html>

I swear I’m really a brilliant web designer but for this example, I’ve created the ugliest page known to man. I have a single GridView control that has some columns defined. This is exactly what I would do if I were using a DataSet as my data source. For those interested on the new GridView control, check out this blog (I hope she gives me a link back!)

I also have a code behind for this page:

public partial class _Default : System.Web.UI.Page

{

GridBinding binding;

protected void Page_Load(object sender, EventArgs e)

{

binding = new GridBinding();

binding.AddRow("Microsoft Corp", "One Microsoft Way", "Redmond", "WA", 92020);

binding.AddRow("Apple", "1 Infinite Loop", "Cupertino", "CA", 95014);

binding.AddRow("Google Inc.", "1600 Amphitheatre Parkway", "Mountain View", "CA", 94043);

binding.AddRow("IBM Corporation", "1133 Westchester Avenue", "White Plains", "NY", 10604);

Page.DataBind();

}

public override void DataBind()

{

Grid.DataSource = binding;

Grid.DataBind();

base.DataBind();

}

My class has a member variable of type GridBinding called “binding” which is set to the DataSource property of the Grid. GridBinding is a class I’ve created that holds a collection of rows of data. The class has a public method called AddRow that allows me to add a new row, passing in address information for my phone book. As you can imagine, this data structure might be created in some other way, returned via a web service, serialized in a database somewhere, or generated on the fly through some sort of user interaction. The reason I can set this object to the DataSource property of the grid is because the object implements IEnumerable.

So let’s take a look at GridBinding. You might imagine I’ve implemented some huge collection class with various methods to work with the data, but you’ve underestimated by laziness. I’ll just be storing the data using a private List<> variable and implementing IEnumerable<>.

public class GridBinding : IEnumerable<GridRow>

{

private PropertyDescriptorCollection _propDescCol;

private List<GridRow> _rows;

public GridBinding()

{

_rows = new List<GridRow>();

_propDescCol = new PropertyDescriptorCollection(new GridPropertyDescriptor[0]);

_propDescCol.Add(new GridPropertyDescriptor("NAME"));

_propDescCol.Add(new GridPropertyDescriptor("ADDRESS"));

_propDescCol.Add(new GridPropertyDescriptor("CITY"));

_propDescCol.Add(new GridPropertyDescriptor("STATE"));

_propDescCol.Add(new GridPropertyDescriptor("ZIP"));

}

public void AddRow(string name, string address, string city, string state, int zip)

{

GridRow row = new GridRow(this, name, address, city, state, zip);

_rows.Add(row);

}

public PropertyDescriptorCollection GetPropertyDescriptorCollection()

{

return _propDescCol;

}

IEnumerator<GridRow> IEnumerable<GridRow>.GetEnumerator()

{

return _rows.GetEnumerator();

}

IEnumerator IEnumerable.GetEnumerator()

{

return _rows.GetEnumerator();

}

So let’s walk through this. First, I have a PropertyDescriptorCollection called _propDescCol. This is a collection of PropertyDescriptor objects. A PropertyDescriptor object is an object that knows how to get a specific property on a certain type of object. If you have a DataRowView object, this object contains a PropertyDescriptor for each column in your row, and the PropertyDescriptorCollection allows you to find the PropertyDescriptor you need when you try to access a property on this row. I could have a PropertyDescriptorCollection in each of my rows, but since they’re all the same, I’ve moved this into the GridBinding class for efficiency (so they’ll only be created one time.)

Next, I have a List<> of GridRows. My GridRow class allows me to store a specific row of information. I can add as many rows as I want using the AddRow method.

In the constructor, I create a new PropertyDescriptorCollection and create a PropertyDescriptor for each property that I want to allow users to bind to. I pass in the name of the property on the constructor, and this is what you’ll use when you’re binding to that property in the grid control.

I’ve also added a method called GetPropertyDescriptorCollection() that allows the GridRow object to retrieve the PropertyDescriptorCollection object.

Lastly, to fulfill the requirements of the IEnumerable<> interface, I’ve implemented GetEnumerable as both a normal and generic method. This simply returns the IEnumerator from my List<> class since I’m using this to store all my rows.

Pretty simple so far, right?

Next, let’s look at the GridRow object:

public class GridRow : ICustomTypeDescriptor

{

private GridBinding _binding;

private string _name;

private string _address;

private string _city;

private string _state;

private int _zip;

public string Name { get { return _name; } }

public string Address { get { return _address; } }

public string City { get { return _city; } }

public string State { get { return _state; } }

public int Zip { get { return _zip; } }

public GridRow(GridBinding binding, string name, string address, string city, string state, int zip)

{

_binding = binding;

_name = name;

_address = address;

_city = city;

_state = state;

_zip = zip;

}

System.ComponentModel.AttributeCollection ICustomTypeDescriptor.GetAttributes()

{

return new System.ComponentModel.AttributeCollection(null);

}

string ICustomTypeDescriptor.GetClassName()

{

return null;

}

string ICustomTypeDescriptor.GetComponentName()

{

return null;

}

TypeConverter ICustomTypeDescriptor.GetConverter()

{

return null;

}

EventDescriptor ICustomTypeDescriptor.GetDefaultEvent()

{

return null;

}

PropertyDescriptor ICustomTypeDescriptor.GetDefaultProperty()

{

return null;

}

object ICustomTypeDescriptor.GetEditor(Type editorBaseType)

{

return null;

}

EventDescriptorCollection ICustomTypeDescriptor.GetEvents(Attribute[] attributes)

{

return new EventDescriptorCollection(null);

}

EventDescriptorCollection ICustomTypeDescriptor.GetEvents()

{

return new EventDescriptorCollection(null);

}

PropertyDescriptorCollection ICustomTypeDescriptor.GetProperties(Attribute[] attributes)

{

return _binding.GetPropertyDescriptorCollection();

}

PropertyDescriptorCollection ICustomTypeDescriptor.GetProperties()

{

return ((ICustomTypeDescriptor)this).GetProperties(null);

}

object ICustomTypeDescriptor.GetPropertyOwner(PropertyDescriptor pd)

{

return this;

}

This is a bunch of code, but you can ignore most of it. ICustomTypeDescriptor supports all sorts of stuff that most of the data bound controls in .NET don’t take advantage of. The first part is easy – I have properties for name, address, city, state, and zip. You must set all of these using the constructor.

Now, let’s go over the ICustomTypeDescriptor methods that we’ll be using here. The most important one is GetProperties(). GetProperties allows you to retrieve PropertyDescriptor objects for all properties or even a specific set of properties. These descriptors are returned back to you in the form of a PropertyDescriptorCollection object. My implementation returns all properties regardless of what you pass in, and as you can see, just calls GetPropertyDescriptorCollection on the GridBinding object. When the GridView control is data binding, it will call GetProperties() and then call Find Property() to seek the PropertyDescriptor for the property that you’re attempting to bind to.

So, in our case, what does GetPropertyDescriptorCollection return? Well, it doesn’t return a PropertyDescriptor object (since this class is abstract), but instead returns a collection of GridPropertyDescriptor objects. This is a class I’ve created to describe a specific property on a GridRow object. In the constructor for GridBinding, we created one of these objects for each property the GridRow class exposes. To my knowledge, there’s no property descriptors built in to .NET, and the ones used internally (such as the one used in DataRowView) are marked as internal. So let’s take a look at the code for GridPropertyDescriptor.

public class GridPropertyDescriptor : PropertyDescriptor

{

private string _propName;

public GridPropertyDescriptor(string propname) : base(propname, null)

{

_propName = propname.ToUpper();

}

public override bool CanResetValue(object component)

{

return false;

}

public override Type ComponentType

{

get { return null; }

}

public override object GetValue(object component)

{

GridRow row = component as GridRow;

if (row != null)

{

switch (_propName)

{

case "NAME":

return row.Name;

case "ADDRESS":

return row.Address;

case "CITY":

return row.City;

case "STATE":

return row.State;

case "ZIP":

return row.Zip;

}

return null;

}

public override bool IsReadOnly

{

get

{

return true;

}

public override Type PropertyType

{

get

{

return null;

}

public override void ResetValue(object component)

{

}

public override void SetValue(object component, object value)

{

//TODO: Set value on component the same way GetValue works...

}

public override bool ShouldSerializeValue(object component)

{

return false;

}

Again, most of this code can be ignored. Let’s go through each method.

First, there’s a private string called _propName. This stores which property of the GridRow this descriptor will be responsible for accessing. This is to be set on the constructor.

The main method here is GetValue. You pass in an object of type GridRow (it would be cool if PropertyDescriptor was a generic class, but it’s not so we have to cast.) Depending on the value of _propName, we return a different property on the GridRow object. If you pass in an object that isn’t of type GridRow, it would return null. Also, if you created a GridPropertyDescriptor with an invalid property name, this would also return null. Perhaps it would be best to check for this, or maybe use an enum for the property name. However, this is just an example so it’s not too important.

The other methods are pretty self-explanatory. Most of them focus on providing information about the property – what type of data it is, if you can change it, if you can serialize it, if you can reset it back to its original value, etc. The method you would need to implement if you wanted to support editing in your grid is, of course, the SetValue method. This method takes a component and a new value. To implement this, you would do the same thing as GetValue only set the value of the property in the GridRow class instead of just return it.

That’s pretty much it! When I run my page, I get the following output:

High-Tech Company Phone Book

Name	Address	City	State	Zip
Microsoft Corp	One Microsoft Way	Redmond	WA	92020
Apple	1 Infinite Loop	Cupertino	CA	95014
Google Inc.	1600 Amphitheatre Parkway	Mountain View	CA	94043
IBM Corporation	1133 Westchester Avenue	White Plains	NY	10604

It’s pretty ugly, I know, but this isn’t an article on how to create pretty grids – there’s already enough of those. Hopefully this gives you a good deal of insight about how data bound controls work and how classes such as DataRowView and Hashtable implement property descriptors to abstract property access. So next time you want to new up a DataSet just to bind to a control, think about writing your own collection class that supports being bound to a data bound control.

Enjoy!

Mike – Web Dev Guy

PS – This blog was posted using the new blog publishing feature in Word 2007, pretty cool!

My thoughts on Monad, the new Windows command line shell

mikechr — Fri, 28 Apr 2006 11:32:00 GMT

Today I decided to install Monad, the new command shell for Windows and I gotta say - this thing is awesome! It's pretty much the most confusing shell I've ever seen, but it combined everything I like from DOS, Bash, Amiga, and the Visual Studio "immediate window".. Basically this thing sits around and creates managed objects in memory and returns instances of those objects.. Those instances can be echo'ed to the command line (ToString is called), or piped into another object.. You can start with simple expressions such as:

1+1

And get back "2"... You can also declare variables such as:

$x = 1+1

You can even call into managed objects such as:

$curdate = [DateTime]::Now

$curdate is actually a manged System.DateTime object, so you can do stuff like $curdate.Date right on the command line.

You can also create an instance of a COM object, such as Internet Explorer:

$ie = new-object -com internetexplorer.application

And then call methods off that such as:

$ie.navigate2("http://www.msn.com/")

The scripting language is pretty nuts and is like nothing I've seen before, but seems to be pretty powerful. However, if you get lost, you can create "CmdLets" which run in process and can be written in managed code. You can easily create CmdLets in Visual Studio, compile them as a DLL, and then call "Add-MshSnapin" on that DLL to register it within the shell. They're easy to debug by attaching to the msh.exe process. When I create a new CmdLet, I specify a verb name (such as Get or Set) and a noun name. I can define parameters for my command as properties of the class. When I run my command from the command line, it's actually creating an instance of that class in memory. If I pipe that command into something else, the actual object is being transferred in memory, not text. Using Reflection, you can also get "tab" command line completion for parameters and what not. You can "capture" all the CmdLets you have active in your shell to an .mcf file so you can easily load them later. In fact, you can create your entire own shell (CmdLets, aliases, script files, etc) and compile the whole thing as an EXE. You can override just about anything you want on the shell, and then just run that EXE as your own person shell with all your customizations that's targetted to your specific need. There's also no reason your shell needs to be command line based. I can make a GUI application that runs on top of Monad as well.

Another great feature is a total abstraction within the file system. Before, you were used to interacting with current file system objects and navigating through folders on the file system. Now, you can do all that, as well as navigate using other providers. Various "MshDrives" are installed, and you can see them by typing "Get-MshDrive". By default, you have drives for mounted disk drives, the registry, ActiveDirectory, Certificates, environment variables, and a few other things. This means you can type:

cd HKCU:\

And you're now in your HKEY_CURRENT_USER registry node. You can type "dir" to see everything and interact with objects just as if they were files.

You can create your own drives as well. I can type:

New-MshDrive -name WinDir -MshProvider FileSystem -root C:\WINNT

And now the WinDir:\ drive is mapped to C:\WinNT. This makes it easy to create shortcuts to long paths.

Since every command uses the same parser, there's various intrinsic parameters that work any any command. For example, I can add the -whatif parameter to show what my command would have done without actually doing anything. I don't really have to worry about parsing parameters on the command line. For those of you who like wildcards, they're way better now. I can pretty much use full regular expressions and search for items or commands. Since everything is an object that exposes properties, I can do stuff like "group" the files by their manufacturer, or search for any dll made by NVidia. I can also search for all processes that take up more than 5 megs of RAM.

Anyway, I could spend hours going on about this and I've only been using this for a day. I've decided to "hide" cmd.exe and use the new shell exclusively, thus forcing myself to get better with it. For a better explanation by the guy who actually designed the thing, go check out:

http://channel9.msdn.com/ShowPost.aspx?PostID=25506

And for an actual demonstration:

http://channel9.msdn.com/Showpost.aspx?postid=25915

If any of you are using this, I'd love to hear your comments and any tips and tricks you've learned so far. I'm a complete newbie and am still doing a lot of exploring.

Thanks,

Mike

Templates - Part 2

mikechr — Wed, 26 Apr 2006 11:24:00 GMT

In my last article, we talked about writing custom web controls that could render UI based on a template. Controls are able to parse properties between their opening and closing tags. These properties can set various public attributes of the control itself or populate the control’s child control collection. These properties can also be ITemplate attributes, in which case ASP.NET is able to create an instance of a template that our control can use for whatever purpose it wishes.

In this part, I’ll be discussing taking this one step further and creating an architecture that can fully abstract control UI using an ASCX file.

Many ASP.NET developers have used ASCX files to define web controls that get compiled at run time. These files behave as “mini web pages” and like web pages have HTML code, server side controls, and server side code. These are nice because they provide developers a way to encapsulate their UI in a separate file without having to “hard code” HTML elements within their code or call Controls.Add() a bunch of times. However, how can one create an instance of these ascx controls at runtime? Well, ASP.NET’s page parser has to do it some how, so how does that work? Let’s take a look.

Once you know that the Page class is actually derived from Control, it’s easy to see how an entire page is nothing more than a control with its child controls specified in an ASPX file, and a web control is the same thing with a different extension. When the page parser comes across a reference to another control, and the reference for that control points to an ascx file, the file is opened and parsed using the Page.LoadControl method. LoadControl has an overload to specify a file name to load the control from. This filename can be (well, should be) an ascx file. LoadControl returns an instance to that control.

So where can this come in handy? Well, let’s take a look at a few examples. The first is this application I’m using right now to post my blog – Community Server 2.0. This software allows blog administrators to upload files to customize the look and feel of their blog site. These files are in the forms of ascx files, and have references to server side web controls to use used as place holders for various blog content. These controls are used to render menus, links, and blog content itself. Taking a look at some of the sample templates will give you a good idea of how everything works. Now, I’ve never seen the source code for Community Server, but I can imagine they call LoadControl to load these user uploaded ascx files into memory from their base class and populate the page’s child controls.

Another example is SharePoint. SharePoint has an entire directory of control templates for their various templated controls. One is DefaultTemplates.ascx which contains a huge list of “RenderingTemplate” instances. The file is loaded in with LoadControl which returns a control collection with all the various templates from the file. Controls.FindControl() can be used to locate the specific template needed.

Should you create one big file for all your templates like SharePoint does? I don’t know, it’s up to you. But in my production code, I have about 20 templates in a single file and it takes no detectable time to parse the entire file. Only the constructors of each object would be called and memory allocation is so blazing fast in managed code, it’s probably not a big deal. But if it makes you feel better, you can create a separate file for each template.

So let’s build a control that can use an ascx file, shall we?

First, we need a control that acts as a container for the template. The template within the container can interact with the outside world through this container class, so anything you template needs access to (such as DataItem) needs to be accessible through this class. You can refer to this instance of this class using the reserved “Container” keyword, such as Container.DataItem. It’s all starting to come together in your head by now, isn’t it?

public class MyTemplateContainer : Control, INamingContainer

{

private TestControl _control;

public TestControl Control

{

get { return _control; }

}

public MyTemplateContainer(TestControl control) : base()

{

_control = control;

}

Our container control is called MyTemplateContainer and only has a single public property called TestControl. We’ll use this as a reference to the parent control that’s rendering the template.

Next, we need a control to reference withinin the ASCX file itself. This control represents a single template instance. When we call LoadControl, we create an instance of this control.

[ParseChildren(true)]

[PersistChildren(false)]

public sealed class MyTemplate : Control

{

private ITemplate _template = null;

[TemplateContainer(typeof(MyTemplateContainer))]

public ITemplate Template

{

get { return _template; }

set { _template = value; }

}

This can have any number of properties which you can set declaratively in the ascx file, but our example just has a single property called “Template”. ASP.NET will automatically set this property based on the contents of the ascx file. So what does our ascx file look like? Well how about something like this:

<%@ Control Language="C#" %>

<Test:MyTemplate ID="MyControl" runat="server">

<table>

<ASP:TextBox Text="<%# Container.Control.TestProperty %>" runat="Server" />

</td></tr>

</table>

</Template>

</Test:MyTemplate>

When we load this ascx file into memory, we create a “Control” object that has a single child control called MyControl that is of type MyTemplate. Inside the <Test:MyTemplate> tag, ASP.NET recognizes “Template” as a public property of the MyTemplate class. It parses the HTML inside the <Template> tag and creates an instance of an ITemplate object. Through the [TemplateContainer] attribute it knows that Container will be an instance of “MyTemplateContainer” so it can verify Container.Control.TestProperty is a valid expression. It would of course be possible to set other properties on the MyTemplate object and read them at runtime. You can also just as easily define other templates, such as Header templates, footer templates, item templates, etc.

Now what about our control itself? Let’s take a look at how to load this ascx file, read the templates, and use them to populate our control at runtime. Here’s what the control code looks like:

public class TestControl : Control

{

public string TestProperty = "Hello World!";

protected override void OnInit(EventArgs e)

{

Control control = Page.LoadControl("ControlTemplate.ascx");

if (control != null)

{

MyTemplate t = control.FindControl("MyControl") as MyTemplate;

if (t.Template != null)

{

Controls.Clear(); //Clear any existing controls

MyTemplateContainer TemplateContainer = new MyTemplateContainer(this);

t.Template.InstantiateIn(TemplateContainer);

Controls.Add(TemplateContainer);

}

base.OnInit(e);

}

Let’s step through this. First, we have a control called TestControl derived from Control. We can place this control on any page we want, or new up an instance of this control at runtime. This control can even be a Web Part that lives in a serialized state in a database some where. It doesn’t really matter since we load the template we need at runtime.

During OnInit, we load our template file into memory and populate our child controls. Let’s step through this:

1) We call Page.LoadControl() to load in our ascx file (defined above.)

2) LoadControl returns a single control that contains all the controls in our file. We know we only have one and we know it’s called MyControl. We know it’s of type MyTemplate so we can use FindControl to locate it.

3) If we found such a control (nobody’s been mucking with our file) and it has a valid Template property, we create a new template container.

4) Through the ITemplate interface, we instantiate our template within the template container.

5) At this point, TemplateContainer will have a populated Controls hierarchy with everything in our template.

6) Now, we simply add the TemplateContainer instance to our control’s child control collection.

Easy enough? Now we have a control that can dynamically load a file on the file system at runtime to populate its UI. This is how SharePoint allows administrators to customize web part and list UI, and this is how applications such as Community Server allow administrators to customize its UI. This allows controls that may appear on dozens of web pages on a single site to all share a common UI template that isn’t “hard coded” into compiled code. Pretty cool, eh?

One thing I thought I’d mention that I ran into when I was experimenting with this stuff initially. The code that builds an ITemplate instance from your <Template> property is not quite as advanced as the default page parser in ASP.NET. It seems you can not do stuff like bind event handlers to server side controls. For example, I cannot do this:

<table>

<ASP:TextBox OnChange="<%# Container.Control.HandleChange %>" runat="Server" />

</td></tr>

</table>

Where HandleChange is a public event that matches the delegate for TextBox’s OnChange event. Event binding is not something this parser supports. However, I would assume it would be possible to write your own “LoadControl” override that can parse the <Template> property and return your own implementation of ITemplate whose IntiantiateIn implementation can bind event handlers. If someone gets that working, I’d love to hear about that.

Let me know if you have any questions!

Mike

Templates - Part 1

mikechr — Tue, 11 Apr 2006 00:48:00 GMT

ASP.NET is, to perhaps oversimplify things, a template parser at heart. An HTTP Handler (anything that implements IHTTPHandler) can be configured to process HTTP web requests and render results for those requests back to the socket. This inferface is quite simple; IHTTPHandler::ProcessRequest is called which is given an HttpContext representing the HTTP request made to the server. ProcessRequest writes a bunch of bytes out to HttpContext.Response (an HTTPResponse object.) IIS handles the rest.

This is great abstraction because it doesn’t force people who like managed code (like me) to use ASP.NET, which might not meet their needs. Nothing would stop you from writing your own HTTP handler and completely inventing your own ASP.NET. In fact, SharePoint has its own HTTP handler that is able to build dynamic web part pages using serialized instances of “web part” controls from a content database, and map other requests to static “layouts” pages to an installation directory containing these files. There are certain charting components that can handle HTTP requests to GIF files and dynamically build a GIF image and write out the bytes to the response stream. IIS is able to map different file extensions to different IHTTPHandler classes via the web.config file.

For those not so ambitious, ASP.NET conveniently provides its own HTTP hander known as System.Web.UI.PageHandlerFactory. This is what you use out of the box and does all the work opening your ASPX files, parsing junk, building Page objects, etc.

PageHandlerFactory figures out what file you’re looking for, opens the file on disk, and parses this file. A “Page” object is created to represent the page with all of its controls. ASP.NET uses a series of server side markup tags to represent these web controls. These web controls are marked with a “runat=server” attribute. For each control it finds, the ASP.NET page parser instantiates an instance of this control, adds it to the control hierarchy, calls all sorts of various methods on it during the life cycle of the Page object, and is able to build a response stream at the end. Other static text is represented as LiteralControl objects. During the Render stage of the page, ASP.NET’s Page class simply calls Render on its top level controls which recursively call Render on each of their child controls.

ASP.NET’s template parsing code is pretty flexible, and in fact you can take advantage of this code in your own controls. You may have noticed certain web controls that have properties of type “ITemplate”. These properties are useful in declarative code in an ASPX file, but not all that useful in code behinds. One example is the Repeater control. This control can repeat some text for each item in some sort of enumerable data source, and can access properties of the current data item. For example:

<ASP:Repeater id="MyList" runat="Server">

<table>

</HeaderTemplate>

</ItemTemplate>

</table>

</FooterTemplate>

</ASP:Repeater>

This control takes a data source, enumerates through it and builds a table with the items found in the datasource. So what are “HeaderTemplate” and “ItemTemplate”? Are they built in to ASP.NET? How are they implemented? Well, you might have already spotted there are ITemplate properties on the Repeater class. ASP.NET is kind enough to build an object that implements ITemplate and set it to these properties of your control for you. So then what does the Repeater control do with them? How can it programmically access the contents of this template and do something useful with it? Also, what is “Container.DataItem” and “DataBinder.Eval?” Let’s take a look at what’s going on here.

So DataBinder is a .NET framework class that provides various data binding functionality, you may recognize it if you read my blog on building your own data bound controls. Eval is a static method that can grab a property (“MyItem”) from an object that exposes a property descriptor (Container.DataItem). If you have no idea what I’m talking about, go read the aforementioned blog. So what is Container? There is no Container class in the .NET framework. Well, Container is an object that represents the current control being generated. In the case of our Repeater control, this is a RepeaterItem object which maps to a specific item in the data source.

When Repeater is databound, it loops through its data set and for each item it finds, it creates a RepeaterItem control. RepeaterItem has a DataItem property that the Repeater control sets to the current item in the data source.

When each RepeaterItem is initialized, Repeater will build the child control collection of that RepeaterItem object by calling the InstantiateIn method of ITemplate:

myTemplate.InstantiateIn(item);

myTemplate is an ITemplate that ASP.NET set for us based on what was in the ASPX file, and item is the RepeaterItem control being initialized. Once this is called, item.Controls will be populated with all the controls defined in the template. Some of these might be other server controls, and others would be LiteralControls representing static text. This is no different than had you called Controls.Add a bunch of times. Inside my template, I can access that instance of RepeaterItem using the “Container” object. Get it?

In my next part of this two part series, I’ll be going into a bit more detail and apply some of these techniques to real world scenarios. But in the mean time, go build a template-able control and see how everything works. They’re quite cool and make it easy for developers using your control to really control the UI layout without having to recompile code and set dozens of properties programmically.

Have fun!

Mike

Too many tiers? Writing efficient multi-tier web applications.

mikechr — Thu, 06 Apr 2006 07:53:00 GMT

A while ago, we were all convinced that dividing our applications up into multiple tiers was the way to go. This was great because it allowed you to scale up the parts of your application that might represent a bottleneck, and have more control over what resources were allocated to what tier. Windows DNA was built on this concept, as well as the whole “Duwamish” architecture. The problem is, this introduces the possibility of a very “sloppy” implementation of this ideal that creates a much larger bottleneck. This is especially true when using slower mechanisms to transport data across tiers.

Suppose you have a SQL Server backend that pretty much spends its time running stored procedures and returning back datasets. You’ve written a stored proc for anything anyone might want to do. You have a middleware component that connects to your SQL backend, and this provides a programmable API to access your SQL data via web services. This abstracts your actual data store from anyone who wants to program against it, and third parties can simply call into managed APIs to get the data they need. No one needs to run some SQL statement or stored proc that might change in the next version. There are no SQL injection attacks, and other problems with front ends running SQL commands. Life is great.

Then, you have a front end written in ASP.NET. This front end calls into your web services to get the data it needs. The problem comes along when the front end (web application) is too tightly coupled with the business layer (web services). The web application might call several of these web methods during various stages of rendering a page. It might call some APIs to validate the user’s credentials, and then call a web method that returns a dataset to bind to a control, also get some menu data, etc. For each of these web service calls, a stored procedure is run. Now, we pretty much have a 1 to 1 mapping between a web service call and stored procedure call. For large data sets, a high percentage (like 40-50% of the page rendering time is simply spent deserializing these datasets across the wire. This is especially inefficient when the web server is running on the same physical machine as the business layer. ASP.NET will open up a socket, connect to IIS, “POST” in a SOAP envelope, get the results, deserializer this back into a DataSet, then return a reference to this object. While this is happening, the thread serving your web page request is blocked waiting for this result (unless you’re using synchronous web service calls, but that’s a huge challenge to design properly.) Yes, it’s true “remoting” can solve some of these problems, as well as Indigo. If you have more users hitting your site than you have available threads, this can cause all sorts of perf problems. Mean while, until the next web service call comes along, your business layer machine is sitting around twiddling its thumbs.

When this architecture was designed, the ideal situation was the higher tiers (meaning the data layer and business layer) were also the lesser used tiers. The business layer would load in all the data it needed to run, cache it and providing an in-memory representation of the data to work with. At an appropriate time, the data could be written back to the database. The presentation layer would request the data it needed from the business layer and then render it into a form suitable to display to the user. In other words, calling into your business layer wouldn’t necessarily mean a call into your data layer unless new data was needed.

For load balancing reasons, everyone seems to want their middleware components to be stateless and not have to worry about caching data and data being out of sync with the database.

Using proper abstraction means that a single call doesn’t drill down into 80 different layers every time it’s called, otherwise why even have this abstraction? The same works for “abstracting” your application into logical layers. If every call is going to drill down into every single layer every time, why have the layers?

I think a better approach for certain applications, especially those who have very simple business logic (ie: just grab some data from SQL Server) is to write business objects as sort of a “data adapter.” My data adapter knows how to get my data from a SQL connection and provide an API for me to read and manipulate it. My data adapter should be in the form of a DLL that my web application links to. The DLL knows how to connect to the SQL Server that it’s configured to use. Multiple instances of my web server, each with their “data adapters” connecting to a cluster of SQL back-ends, can be running to scale up to the demands of my users. This is still a layer of abstraction, but doesn’t have a massive bottleneck marshalling the data across the wire between tiers. If my front end is super dependent on this data access API, each call should be as lightning fast as I can make it, and that means running it in the same process so I can just return a live pointer to my object.

I could also write a separate web service that also links to my “data adapter” DLL, but provides a SOAP based interface to my API. My application doesn’t need to use this, but third parties that wish to program against my backend can easily use this interface. There’s really no reason for my own application to be accessing my own business layer via SOAP, it’s inefficient and results in blocking threads and dragging down the CPU. The amount of effort it takes to marshal a large chunk of data across SOAP is simply not worth the extra scalability that I’m not convinced I’d really have anyway. In fact, connecting two tightly coupled tiers that are both owned by me and controlled entirely by me should not be talking in an extensible human readable, 7bit protocol – especially if I’m doing this 30 times for every page I serve up.

If you’re building such an application, I’d be interested in hearing your comments as far as architectural decisions and scalability, and if you’ve done any stress testing with large amounts of data, where your bottlenecks are. It’s my opinion that flattening out these tiers into a single process running ASP.NET code and an adapter that can connect to a data backend is the way to go, especially when using SOAP. I’d love to hear your comments!

Mike

My initial thoughts on "Indigo" (Windows Communication Foundation)

mikechr — Tue, 04 Apr 2006 04:16:00 GMT

Recently, I took an extensive in-depth course on Indigo, Microsoft’s new platform for allowing applications to talk to each other easier. I’ve decided to write a blog on this topic, sharing what I’ve learned with others.

Indigo is an attempt to replace DCOM, MSMQ, COM+, Web Services, ASMX, Remoting and other technologies designed for inter-application communication. The Indigo team has incorporated the strengths of these older technologies into this new platform, and designed Indigo to position itself as a replacement for whatever technologies current products are using. Teams that are using Remoting will refer to Indigo as the next generation of Remoting. Teams using Web Services will look at Indigo as the next generation of web services. Indigo has also been designed to easily “Interop” with older technologies. Right now, applications that use ASMX to connect to the a business layer could be rewritten using Indigo, and the front end would not require any code changes as Indigo would be able to emulate standard SOAP 1.2 messages and XmlFormatter serialized return objects. An Indigo client application would be able to communicate with ASMX web services, or even send objects to an MSMQ based queue service. The Indigo team has gone out of their way to ensure smooth transitions between old and new technologies, and guaranteed no one will have any excuse not to upgrade due to incompatibility.

Indigo is built on “channels”, which describe how data is moved from one place to another. There are two kinds of channels, protocol channels and transport channels. This abstraction guarantees that the way an object is actually encoded (or serialized) is completely independent of the way it’s moved across the wire. A protocol channel may serialize an object using XML based on the SOAP specification. Or a protocol channel could use a binary encoder to encode data in a very tight and efficient binary form. One could write their own protocol channel to do their own custom encoding, handle encryption, etc. Unlike ASMX, we are no longer tied to using SOAP or XML based encoding to encode an object, and no longer tied to HTTP to transport that object. A transport channel takes this encoded instance of an object and transports it across the wire. Out of the box, Indigo has several transport channels. The easiest to use (and default) are the Basic bindings. An Indigo server binds itself to a Network interface, opens up a listener socket on a port of your choice. An Indigo client would connect to that port and transport data directly over TCP. Note, this has nothing at all to do with IIS, nor does it even use IIS. This is simply just socket to socket communication. Indigo also supports transports such as HTTP, HTTPS, named pipes, MSMQ, UDP, etc. Indigo can be hosted in a simple console application, it can run under a Winforms application or an NT service, or can be “hosted” in the IIS app domain and run under ASP.NET. One could write their own transport protocol to handle their own communication, such as a shared memory protocol for truly optimized data transfer, or a protocol that was intelligent and would do the right thing based on the network configuration.

Indigo works on a stack of channels, channels can be combined and stacked on top of each other. One channel can do encryption, others can authenticate data. There can be intermediaries to intercept and proxy requests. Indigo is designed to be truly flexible, any piece can be overridden using behaviors. Developers can override the raw socket code, construct their own XML messages by hand and play with any aspect of the platform down to the lowest level, or they can sit back and write 3 lines of code so Indigo will do everything for them. Indigo offers a style where you can pick and choose which components you want to use and which you want to implement yourself. Classes can be tagged with various [Attributes] to define how Indigo should handle them.

This platform also supports security out of the box based on the WS-Secure standard. Indigo provides the following security types: Anonymous, Windows Auth, Username and certificates. It also supports impersonation and passing around security credentials through a medium. Indigo can handle sessions per user, go sessionless so that each web request instantiates a new handler object, or create a Singleton handler class which the first time a request is made, the handler will be new’ed up and then saved in memory for future requests. This is a huge improvement over ASMX where session state is near impossible to do right.

Transactions are also very strongly supported via .NET 2.0’s System.Transaction.dll component. Transactions can be serialized across the wire and Indigo can manage transaction states.

Indigo also has a very dynamic way of handling errors and exceptions. Obviously, you wouldn’t want an exception object returned directly from a web service. You might not want the customer having a full stack trace and inner exceptions. So Indigo has the support to return “faults”, which will end up triggering an exception down on the client but only contain desired information from the server. Developers can build their own fault types that encapsulate any error information they want.

Indigo also provides much more advanced serialization. Serialization is now 100% WS-* compliant. Circular references in serialized objects are now supported, as well as a very flexible security mechanism. SOAP packets can be tamper-resistant: they’ll be unencrypted and human readable, but if the contents are changed the platform will catch it. SOAP packets can also be encrypted, the header contains a hash value to ensure the packet is not tampered with and the <body> will be encrypted through one of the default encryption providers or through custom code. The platform will handshake with the client to setup a secure session very similar to how SSL works: The client will ask for a certificate (or a public key) from the server. The client will then generate a random number, then encrypt that number with the public key. The server, having the private key, will be able to decrypt that number, and that number will then be used as a key to sign future messages between the client and server. Using this method, messages themselves are secure, not the actual transport. One could still use SSL to secure the transport, but encrypting the messages themselves allows for an untrusted intermediary between the client and server without the need to re-encrypt, and it’s also much more efficient. All this is out of the box, customizable, and available for free from the Indigo platform. It took about 4-8 SOAP messages (depending on the setup) echoed back and forth between the client and server to setup a secured session, and after that the overhead was minimal. Also, this security is turned on by default and you’d have to go out of your way to disable it.

Indigo also supports the new SOAP based reliable messaging standards. No longer will you send off a SOAP request to the server and have no idea if the message was actually received or not. The server can send back a SOAP message basically saying “I didn’t get the message with the following ID, can you resend it?” and the platform will take care of resending the message for you. The concept of message order can also be preserved on web methods that so indicate. I can send your server 100 messages, and if message 10 is not received properly, the server will send back a request for message 10 and suspend processing messages until message 10 is received. In the mean time, received message 11+ will be stored in a queue until 10 is received, at which time, 10 and on will then be processed. This same queue mechanism provides a large amount of scalability under heavy loads. All of this only took a few minutes to implement.

There are also some improvements that the IIS team is making for IIS7, under Longhorn. IIS7 is no longer tied to HTTP and HTTPS. IIS will be able to host services that use TCP sockets, named pipes, etc. There’s really no reason to use HTTP unless you’re calling a service over the Internet or over an HTTP proxy.

Overall, I’m quite excited by this platform and it’s given me a few ideas for using this technology in my own work. I’m impressed by what the Indigo team has done, and it takes quite a bit to impress me these days. Indigo is definitely a fantastic platform and provides the power to do exactly what you want, how you want it by writing custom behaviors, implementing certain interfaces and deriving from a whole set of carefully crafted base classes. This two day 16-hour class barely touched the basics of this new platform, and I expect to see huge books written on Indigo in the next year or two.

Mike

Building your own data bound controls...

mikechr — Sat, 01 Apr 2006 09:14:00 GMT

In any Web Application, you have data bound controls. The job of a data bound control is to transform your data from some arbitrary format into the format it probably should have originally been stored in. In fact, about 90% of computer code simply converts some chunk of data from one arbitrary format to another arbitrary format.

Let’s say I have some data in a SQL Server which is stored in some highly optimized format on a disk somewhere. I can read it, but I access it through a connection that gives me that data in some sort of ADO.net record set format. This is great because I can return that object from my web service. The web service will serialize the data into SOAP. SOAP is a human readable representation of data that usually won’t actually be read by any humans. SOAP is great because it’s all text based so it supports 7bit token ring networks, so you don’t have to worry about upgrading your network.

So anyway, on your web front end you’ll get the SOAP and the deserializer will parse this text and build the dataset you just had a second ago. Then, you bind that dataset to an ASP.Net DataGrid control of some sort. This article will eventually detail exactly why that is so nifty after I’m done with my rant.

When DataBind is called, the grid control will loop through your dataset using its IListSource implementation. Inside, it builds DataGridRow objects which basically store the same thing as a DataRow, but since the DataGrid isn’t necessarily binding to a DataView, it has to create its own row abstraction. The grid does this and is happy, and then later on the framework calls CreateControlHierarchy. This tells all the controls to convert their data into a bunch of System.Web.UI.Control objects because that’s what ASP.NET likes to have around.

So the grid loops through its collection of DataGridRow objects and creates a bunch of TableRow controls, each one of those having a bunch of TableCell objects depending on what columns are bound to your grid. So ASP.NET has in memory this massive tree of Control objects. What does it do with it? Well it calls a bunch of stuff on each item such as OnInit, OnLoad, and OnPreRender. Oh, and somewhere in there it loads and saves the ViewState from some massive serialized blob.

Eventually, ASP.NET calls Render on all of these controls, and all Render does is translate the data into HTML, which is simply yet another representation of that same data. HTML comes in handy because it’s human readable and easy to transmit over your 7bit token ring network. Also it’s flexible and easy to work with since the standard is bound to change (if HTML were binary, FrontPage sales would have skyrocketed.)

So this is all transmitted over a socket and dumped out to whoever happens to be listening. Ideally, this ends up being parsed by a web browser, such as Internet Explorer. Internet Explorer eats up this nice HTML and builds a DOM (Document Object Model) out of it. This is a binary representation of your control hierarchy so IE can work with it (computers don’t like human readable text because they think humans are weak and inefficient,) manipulate stuff quickly, and present an object model to anyone who cares to program against it (like all you scripters.)

IE will finally draw this data out on the screen in a matter that’s pleasing to the eyes (for those of us who wouldn’t be able to look at The Matrix in its encoded form.)

So this is nice and efficient, we only looped through the same data about 100 times and didn’t really change anything. So what’s my point with all this? I’m not sure, but it would be cool if the control hierarchy that ASP.NET creates was the same as the one that IE uses, and we could just transmit it directly over the wire. Maybe someone wants to write that ActiveX control and IIS extension? No, actually what I’m saying is that often instead of focusing on how to optimize your for loop, you should be focusing on whether that loop is needed in the first place. Ok, end of rant – onto point of article.

.NET Data Bound Controls

So ASP.Net, well – actually pretty much the entire .NET framework – is quite nifty in the fact that you can pass any control a “DataSource” and it somehow magically knows how to read it and use that to populate itself. So what is a DataSource object anyway? Well, let’s see – I can pass in a DataSet which is nice. If it’s a small chunk of data that I can hard code into my program, I can pass in an Array or an ArrayList. If I need a key value pair, I can pass in a Hashtable. All of these work, that’s cool! So I bet these data bound controls have a bunch of “if _datasource is Array then do this” and “if _datasource is Hashtable then do that” blocks. But wait, I can write my own class and implement IEnumerable or IListSource and that works too.

So how do these data controls work and what if I want to build my own? Well, I sat down and read through a bunch of ASP.NET source code such as the DataGrid, DropdownList, Repeater, etc. They’re all pretty much the same and work in the same way. So I wrote my own little control that takes a data source and just dumps out the items to the console. It looks something like this:

class Program

{

static void Main(string[] args)

{

MyControl[] controls = { new MyControl(), new MyControl(), new MyControl() };

controls[0].DataSource = new string[] { "One", "Two", "Three" };

controls[0].Render();

controls[1].DataSource = Data.GetHashTable();

controls[1].DataField = "Value";

controls[1].Render();

controls[2].DataSource = Data.GetDataTable();

controls[2].DataField = "Name";

controls[2].Render();

}

As you can probably guess, Data.GetHashTable just “new”s up a hash table and returns that. Data.GetDataTable() creates a data set from an XML file and returns that. I won’t include the source to those things because it’s not all that exiting. So I run my program and it writes out to the console:

Writing object of type: System.String[]

One

Two

Three

Writing object of type: System.Collections.Hashtable

Fish

Cat

Dog

Writing object of type: System.Data.DataTable

Apple

Banana

Orange

Pretty amazing I think. So how does my control work? The same way all other .NET data bound controls work. First off, it supports binding two types of objects – IEnumerable and IListSource. IEnumerable would be a hash table, array, ArrayList, etc. An IListSource would be a DataSet, DataTable or DataView.

The first thing my binding code does is check if it’s an IEnumerable. If so, the job is pretty easy. My control likes IEnumerables.

IEnumerable list = null;

if (_datasource is IEnumerable)

{

list = (IEnumerable)_datasource;

}

Wow, that’s great. Now we have an object called “list” which is my data source as an IEnumerable. But what if it’s an IListSource? Well, if it’s an IListSource then I want to convert it into an IEnumerable because I want to foreach through it. For those of you who aren’t fluent in C#, “foreach” is basically just short hand for calling IEnumerable::GetEnumerator() which returns an IEnumerator, then calling MoveNext() a bunch of times of that. Thus, you can only “foreach” through an object that implements IEnumerator.

So anyway, if I have an IListSource I have the following snippet of code:

else if (_datasource is IListSource)

{

IListSource listsource = (IListSource)_datasource;

IList memberList = listsource.GetList();

list = (IEnumerable)memberList;

}

Weird, what does that all do? So first, IListSource has a method called GetList(). This returns an IList. Know what’s truly amazing and comes in handy? The fact that IList is derived from IEnumerable. Using that, we can set our “list” object to an IEnumerable (which can enumerate an IListSource.)

So now we can iterate through, uhh – stuff. What stuff? I don’t know. The Array class’s GetEnumerator() implementation returns an IEnumerator that can iterate through objects in the array. Hashtable returns an IDictionaryEnumerator which represents key/value pairs. DataTable returns a collection of DataRowView objects. So I can’t just print those out to the screen. Plus, I’m not sure exactly what item I want. Wait, didn’t my “DataField” property specify what item to get? How does that fit in? How can I get a property of these objects based on a string? Well the answer to that is in Property Descriptors.

Property Descriptors are among the niftiest .NET freatures and allow you to abstract property names from the actual implementation of a class. I can say GetProperty and pass in a string, and my class knows what to return. Hashtable, DataRowView, etc all implement property descriptors which allow this to work. GetProperty on a DataRowView expects a name of a column, which is why you can set the DataField to a column name. Hashtable expects the string “Key” or “Value” which is why you can bind to a hashtable. One of these days, I’ll write a whole article on property descriptors and how can you write your own, but in the mean time we’re going to cheat and use a utility method that is part of the .NET framework. The DataBinder class has all sorts of methods that come in handy for people writing data bound controls. One of these methods is GetPropertyValue. You can pass in an object and which property you want to get, and even an optional formatting string, and it returns back a string for you. Using this, our foreach loop looks like this:

foreach (object obj in list)

{

string text;

if (_datafield != null)

text = DataBinder.GetPropertyValue(obj, _datafield, String.Empty);

else

text = obj.ToString();

Console.WriteLine(text);

}

Well there you have it. You can now write your own data bound controls that work just like the ones that come with ASP.NET! Play around with this, see what sorts of data you can bind to your control and try writing your own collection classes as well. In my “Property Descriptors” article, I’ll be writing a collection class that you can bind to the ASP.NET DataGrid if you’re too cool for DataSets. Stay tuned!

Mike