Linq To SQL

Linq to SQL is an object relational mapper (ORM) that is included in .NET 3.5.  The Linq to SQL designer allows you to create objects from you database tables simply by dragging the tables from the server explorer to the design surface.  You can customize the generated types in the designer or write code in partial classes.  Once you have defined your model, you can query it with Linq syntax and the SQL provider will generate the appropriate database calls for you.

One limitation of Linq to SQL is a given object can only be populated from one table.  This means that your object will map almost one to one with your database tables.  For anything but the simplest applications, you don't want to work with the database tables.  For these situations, you could use Linq to SQL to populate domain objects.  Keep in mind that there is a performance overhead in creating these objects as opposed to using raw ADO.NET.  Rico Mariani has a good series of blog posts about Linq to SQL performance, but I suggest profiling your application if you think it will be a problem.

ASP.NET 2.0 Databinding, Part III

In part I, I covered datasource controls and two way databinding.  In part II, I went into how to use table adapters for handling CRUD operations with two way binding.  Today I want to explain when it makes sense to use these features.

It is important to keep in mind that any technology, feature or pattern will only be useful in a certain context.  Two way databinding is a good fit for single table editing scenarios in applications that will not get heavy user loads.  For more complex joined data you have to write code and it forces you into a very data centric and hard to test design.  For applications that have complex editing scenarios you are often better off handling the GridView events directly.  If you are designing a system with lots of business rules, you should probably using a rich domain model.  I intend to write a post about using domain driven design patterns soon. 

By the same token, there are other options for handling data presentation.  Depending on you needs, you might want to consider using a commercial grid control like Telerik, Infragistics or Ext js.  Many of these controls will handle updating your datasource object for you, which gives you more freedom in the design of your data access strategy.

If you found this series useful, saw a mistake or have any questions please let me know.  I am always interested in feedback, so feel free to leave me a comment.

ASP.NET 2.0 Databinding, Part II

In part I, I talked about DataSource controls and how they enable two way databinding. Table adapters are another new feature of ASP.NET 2.0 that was designed to work with the ObjectDataSource to allow declarative databinding.

What do I mean by declarative? At a high level, declarative simply means you state what you want, not how you want it done (as opposed to imperative, where you say how something should be accomplished). When these terms are applied to ASP.NET, it usually means aspx markup (declarative) or C# code in your code-behind classes (imperative).

Table adapters generate ADO.NET code, specifically SqlDataAdapters and handles all the database connections for you. Using the designer in Visual Studio we can drag and drop tables, specify stored procedures or ad-hoc SQL and VS will generate a strongly typed DataSet based on the shape of the query, and a SqlDataAdapter for each query you add.

The code that is generated by the designers are partial classes, so you can add methods and properties or handle events on the table adapters or the DataSets they return. The usual example is adding validation logic, which is a nice idea, but implementing the validation with the ASP.NET validation controls generally provides a better user experience.

The table adapter classes and the query methods they expose are decorated with attributes that tell the databinding designers they support certain operations. You could implement your own objects that can work with two way binding that persist to a completely different database, or call a set of web services.

The first query you add to a table adapter defines the shape of the DataTable that is generated for you. If this query is a single table select statements, the designer can generate the insert, update and delete methods for you, otherwise you must manually write the SQL.

In part III, I will put the pieces together and look at where two way databinding and table adapters are a good fit.

ASP.NET 2.0 Databinding, Part I

This is the first of a series of posts about databinding in ASP.NET 2.0. These posts are mostly for my understanding and writing practice, but hopefully someone gets value out of them as well. To whoever does read this, I would love to hear some feedback.

The features I will be talking about are covered in a set of tutorials by Scott Mitchell that are much deeper and more detailed than these posts.

In ASP.NET 1.1, databinding was a manual, one way operation. You set the DataSource of a UI control to a collection and call DataBind. This is great, but what about getting the data back from the UI control? You have to manually access the values from the control and write code to map the values back to some kind of object.

In ASP.NET 2.0, there is support for two way databinding. What do I mean by two way? When a command is issued to a bound control, it will check if the DataSource object it is bound to supports the given command. If it does, the data will be passed back to the datasource control which will handle the operation (update, insert, delete).

This implementation has several parts. First, all data-bound controls now have a DataSourceID property. This property should correspond the ID property of a DataSourceControl object. These controls handle calling DataBind on the control and can be configured to handle most of the command events for a bound control (Edit, Update, Cancel, Delete, and Insert). Keep in mind that although DataSourceControl objects are part of the System.Web.UI namespace, they do not render anything themselves.

For the datasource to work, you must at least configure it to handle fetching data. For an ObjectDataSource, this means pointing it to an instance method that it should call to fetch the data. For a SqlDataSource, you have to give it a connection string and a select statement.

In part II, I will show how to use an ObjectDataSource in conjunction with TableAdapters (another ASP.NET 2.0 feature), to allow CRUD operations against a SQL Server database without writing a single line of C# code.

Took the Plunge

I have been thinking about starting a blog for a while, so I am finally writing my first post. I recently attended the alt.net open spaces in Seattle, and some conversations I had there made me decide to start a blog. A little background; I have been a computer geek since I was a kid, but I never did any amount of programming until I started college in 2003. I have been working as an ASP.NET developer since January 2006, and I graduated from school in the beginning of 2007. I'm not sure what the goal of this blog is yet, for the time being I am going to post problems I run into ( and hopefully resolve:-) ). Hopefully other people will get some benefit from it as well, but if nothing else, it will be a good reference for me.