Update: I refactored some of the code and also did a better job ensuring Dispose() is called everywhere so that the DataContext object gets cleaned up properly.
.NET 3.5 has a lot of great new features that can significantly enhance developer productivity. I've been spending some time lately working on a little sample application that demonstrates how an N-Layer ASP.NET 3.5 application can be built using LINQ, lambdas and LINQ with stored procedures. The application is for a talk I'll be giving at DevConnections in April discussing how LINQ technologies can be used in an N-Layer architecture. In a previous post comparing different LINQ options I mentioned that I'd be posting the code download as soon as it was ready.
The application provides a presentation layer, business layer, data layer and model layer through separate projects as shown next:
It also demonstrates how the new ListView control can be used to display data, perform insert, update and delete operations and nest other controls such as the GridView. Databinding on the presentation layer is mainly done using the ObjectDataSource control.
All of the queries performed in the application go against an object model created using the Visual Studio 2008 LINQ to SQL Designer.
Note: The included Northwind SQL Express database has been modified slightly to add a TimeStamp field into the Customer and Orders tables and contains several custom stored procedures (sprocs aren't required unless using that portion of the application). Adding TimeStamp fields simplifies updates so be aware that if you change the connection string to point to a standard Northwind database you'll get an error since the TimeStamp fields will be missing.
3 Options for Data Access
Rather than focusing solely on LINQ, I wanted to show different options for data access that .NET 3.5 offers so that developers can get a feel for what's available in addition to standard LINQ queries that seem to get most of the attention these days. I ended up creating six main data layer classes as shown next:
Customer Query Classes:
- CustomerDBLINQ - Executes customer related queries using inline LINQ
- CustomerDBLambda - Executes customer related queries using lambda expressions
- CustomerDBSprocs - Executes customer related queries using stored procedures and LINQ
Order Query Classes:
- OrderDBLINQ - Executes order related queries using inline LINQ
- OrderDBLambda - Executes order related queries using lambda expressions
- OrderDBSprocs - Executes order related queries using stored procedures and LINQ
I still lean toward using stored procedures due to the security and maintenance benefits they offer in more enterprise environments, but for small queries I actually prefer lambda expressions over LINQ (not sure why...just feels more object oriented I guess). If you currently use stored procedures in your applications and haven't checked out the new LINQ to SQL Designer you'll be impressed with how easy it is to call stored procedures and pass parameters. You never have to see or create another SqlCommand or SqlParameter object again (well...in many cases anyway).
Switching Between Data Access Classes
By changing a value in web.config you can switch between the different data layer classes and see which option you prefer (LINQ, lambdas or LINQ with sprocs). All of the data access classes perform the same overall tasks, they just use different techniques to do it.
<appSettings> <!-- Used to define which DB layer class should be loaded and used. Valid customer values include: Data.CustomerDBSprocs, Data.CustomerDBLINQ, Data.CustomerDBLambda Valid order values include: Data.OrderDBSprocs, Data.OrderDBLINQ, Data.OrderDBLambda --> <add key="CustomerDBType" value="Data.CustomerDBLINQ" /> <add key="OrderDBType" value="Data.OrderDBLINQ" /> <!-- When the following key is set to "true" ensure that
EnablePartialRendering is set to false on the Default.aspx ScriptManager control --> <add key="EnableDataContextLogging" value="false" /> </appSettings>
Over the next few weeks I'm hoping to make some time to walk through the application pieces. I may create some video tutorials about it as well....we'll see how time goes.
Last night we released a new version of the OrgChart.NET ASP.NET server control under a new name of "SmartChartPro". We decided to give the control a new name since it's capable of doing more than just OrgCharts (although that's what most companies use it for). We also released a new company website named SmartWebControls.com based on .NET 3.5 where SmartChartPro and other upcoming controls will now reside.
Scott Guthrie just released new information about Silverlight 2.0 including 8 tutorials. It's going to be a "happening" client-side development framework once it's all done! Here's a list of the tutorials he released:
One of the cool features in VB 9.0 is the ability to work directly with XML in code without having to wrap quotes around everything. If you're a C# developer, that's a feature that we don't have although you can do similar things with LINQ to XML (quotes required though).
I've been developing for months on Windows Vista and had everything I needed at my disposal. Last night, however, I needed to test whether or not email messages were being successfully sent from an ASP.NET application and see what they looked like. I went to look for an SMTP server in Vista Ultimate and quickly found that there isn't one. IIS7 includes email forwarding capabilities, but I wanted a simple SMTP server (or something that could emulate one) so that I could see the email messages that were being sent.
There's a lot of great stuff in .NET 3.5 and several different ways to work with LINQ technologies such as LINQ to SQL. I'm currently putting together some demonstration code for a talk I'll be giving at DevConnections in Orlando and showing how LINQ, Lambdas and LINQ with stored procedures can be used to do the same thing so that people get a feel for each technique. For shorter queries I generally prefer lambdas since it's more object-oriented feeling compared to LINQ (to me anyway). For more complex queries LINQ is much easier though. Overall, I still prefer stored procedures since you have much more control over security that way and can maintain queries without resorting to C#/VB.NET code changes in some cases. Plus, LINQ makes it really easy to pass parameters to stored procedures without having to create SqlParameter objects (something I've always despised).
I've been working with the new ListView control in ASP.NET 3.5 combining it with LINQ and Lambda expressions and was finding myself duplicating a lot of code between ItemTemplate and AlternatingItemTemplate templates (I'll be posting the sample application that demonstrates using LINQ, Lambdas and Stored Procedures soon). The AlternatingItemTemplate contained the same code as the ItemTemplate except for a CSS class added to the first <tr> element to change the background color. Here's an example of both templates that were used initially:
Thanks to everyone that attended the CS300 class last week at Interface Technical Training. I had a great time and enjoyed meeting everyone. You can download the on-the-fly demos relating to ADO.NET, events, Web Services and the BackgroundWorker here. The complete set of samples for the course can be download here.