Microsoft's PDC 2008 Conference was held this week. You can go to the following link and watch any session absolutely free on just about any Microsoft development technology or environment that you can think of:
https://sessions.microsoftpdc.com/public/timeline.aspx
View Full ArticleSomeone just sent me a link to a blog post talking about one of the new features of C# 4.0 that will be included with Visual Studio 2010. It is regarding covariance and contravariance support within the C# language. This support has been included since C# 2.0 (and consequently, .NET 2.0). However, it is currently flawed for delegates and interfaces using generics. Follow this link to find out more about the proposed improvements for the future version of C#:
View Full ArticleI've been following Rob Conery's ASP.NET MVC Storefront project that he has been broadcasting to the world via webcasts. This project has been going on for over 6 months now and there are currently over 20 videos to watch if you really want to get up fully up to speed (which will literally take days).
Anyway, it's a Storefront website application built on technologies such as Windows Workflow, ASP.NET MVC, CardSpace, StructureMap, PayPal Standard, OpenID, and many others. While slowly connecting all of these technologies together, Rob attempts to really learn TDD at the same time. He's an employee of Microsoft.
One of the things that I really like that he did was to modify the Repository Pattern slightly by adding in Pipes and Filters Pattern on top of it using the IQueryable<> generic in LINQ. It really is brilliant in my opinion, and if you want to get totally up to speed with just this small part of his project, watch the first 3-5 videos of Rob's Storefront project. Then read a blog post by him about an issue he ran into and how he fixed it; the link to his post is at the bottom of this blog entry.
In the process of making this new Repository pattern, he came across some issues with trying to do true Lazy Loading of an object's relationships to other objects within his LINQ queries. Basically he wanted to harness the power of IQueryable used by LINQ queries to create the expression that queries against the database but not execute it unless needed. For instance, if you've got a Product object in your model and it contains a collection of UserRating objects, there will be times when you want to retrieve a Product with its UserRatings and times when you only need the Product. The most efficient way to do it (and coolest) would be to retrieve the object and its relationships the same way every time and let the IQueryable magic of LINQ know when to execute the query against the database and when to leave it as an unexecuted expression.
So Rob created the LazyList object that holds the IQueryable expression until you need to iterate over it or retrieve one of its elements, where it executes the query and fetches real data from the data source. Rob ran into some unexpected issues with the relationships not loading lazily but was able to solve the problem by using the keyword let in LINQ. Read his full post about the issues and fixes (and get the source code for the LazyList class) at the following link:
http://blog.wekeroad.com/blog/lazy-loading-with-the-lazylist/
View Full ArticleA while back, I went on a research binge about LINQ and Lambda Expressions in C# 3.0. In my research I also learned about the amazing IQueryable<> generic. I was just recently reminded of this knowledge surge and figured it could probably benefit many people.
So here are some links I think you just might find as interesting as I do:
I attended an MSDN Unleashed Event here in Salt Lake City yesterday based mostly on the new bells and whistles in .NET 3.5 SP1 (and consequently Visual Studio 2008 SP1). I always enjoy the presentations from Rob Bagby, as he is entertaining to listen to and he is a let's-dive-into-the-code, forget-about-Powerpoint-slides kind of presenter. He is a Microsoft Developer Evangelist (click Role Descriptions on the right column of the page this link references) for the Rocky Mountain states inland from the Pacific Coast. That's just the way he rolls.
Anyway, he was trying to add some functionality to ASP.NET Dynamic Data for a demo he was showing during the event, and he mentioned a conversation he had with some of the developers at Redmond about the possibility of partial Properties. According to his words, the impression he got was that "if partial Properties were added to C#, the whole CLR would catch fire" or some other horrible catastrophe. But Rob did mention the little-known existence of partial Methods in C# 3.0, which caught my attention and sent me surfing.
See my last post about partial Classes if you want some background to partial Methods.
The genesis of this new feature is much the same as that of partial Classes, which is primarily for Classes that are auto-generated by code generators in Visual Studio (mainly associated with the numerous designers incorporated into Visual Studio). In fact, it appears the addition of LINQ may be one reason for this new feature.
Partial Methods seem to be a way to incorporate into your Classes methods that may or may not be implemented, kind of a way to stub out areas where another developer could inject specific logic they require into a pipeline of statements they didn't write. Partial Methods can only reside in partial Classes, and can only have one declaration and up to one optional implementation. They must be private, have a void return value, and there are quite a few modifiers that cannot be used on a partial method. For a more comprehensive detailing of these restrictions (and explanations why), see this blog post by Bart De Smet that I read to learn about this new feature:
Apparently, LINQ-to-SQL makes use of this new language feature to allow the developer to plug their own business logic validation rules without modifying the auto-generated code directly. If you go to a LINQ-to-SQL generated Class, you will find a C# region named "Extensibility Method Definitions," which are partial Method declarations (see first image below). This allows you to make a separate file that is a partial Class of the LINQ-to-SQL generated class and include an implementation for one of these partial Methods, which are by default unimplemented. It appears LINQ-to-SQL allows you to plug into some of the setters of the generated object Properties that map to columns in the original SQL database table. The following images are taken from Bart's blog post and are LINQ-to-SQL generated objects based on some of the DB structure for Team Foundation Server:
Here are some partial Method declarations in a LINQ-to-SQL generated Class called BuildCoverage:
And here is the view of the LINQ-to-SQL generated object in the designer so you can see that most of these partial Methods are based on the object's Properties:
Here is a look at a Property setter calling these unimplemented partial Methods:
And if you wanted to implement one of these partial Methods, you get nice intellisense from Visual Studio:
And I suppose this finished implementation of the partial Method would throw a NotImplementedException after the Property has already been modified? Hopefully this is where some of that LINQ-to-SQL transactional stuff kicks in...or perhaps Bart meant to implement the OnAssemblyNameChanging partial Method instead?
This is definitely an interesting new feature in the C# language. I'll have to keep my eye out for a really compelling use of this feature; I'm not very convinced this is the right way (or even the most common way) for using LINQ-to-SQL generated objects as if they were your Data Model objects and then insert your business logic in the above manner. Still, this is quite a thought provoking new feature.
View Full ArticleMany .NET developers are aware of the idea of partial Classes, as they have existed since .NET 2.0. The primary purpose is to allow you the developer to share claim on a C# Class with Visual Studio's automated code generators (mainly used by the many designers included in Visual Studio), without the automated code generator stomping all over your code additions every time it runs. For instance, in a Windows Forms application, you get a code-behind Class where you can put your logic, properties, methods, and event handlers; it is a partial Class of the one Visual Studio's Windows Form designer creates and manages for all the UI objects you dragged around in the designer. A good summarization of this feature is given by Bart De Smet:
"In short, partial classes allow you to split the definition of a class across multiple files, or alternatively you could think about it as a code compilation unit separated over multiple files."
As another practical application of this feature, I have occasionally implemented a practice using partial Classes that I learned from a previous coworker. Occasionally you find yourself with a Class that is inescapably large. Perhaps it is a web service that has been in use for a while by customers or other groups within your company, and you can't just deprecate the service very easily; so you just keep extending it and adding more web methods to it for additional, similar functionality. Another potential situation could be that you began designing a simple application all in one file but it grew to be a little bigger than expected, but it doesn't quite merit a whole major redesign into appropriate classes. I know how this all sounds, but these scenarios aren't exactly uncommon in real-world practice, where there are other factors in consideration. I suppose many would resort to C# regions, but I'm not a fan of them as it really only gives the illusion that your code file is better grouped and somehow shorter.
So if you need some decent semblance of organization in a messy class file with little effort, the partial Class feature can come to your rescue. You can basically create a partial Class file for each grouping of code that you would probably be putting in a C# region. For instance, a relatively small Windows Form application could be broken up into the following sub-files (all partial Classes of the same MainForm class):
Obviously you should try to architect your code better from the get-go, but perhaps what you are looking at is legacy code you have inherited from previous developers and the deadline is fast approaching. There are reasonable circumstances I can think of (and have encountered) where this quick & dirty organization lets you keep an ounce of sanity, so that you can keep moving forward.
View Full Article
