A New Way of Learning
At the moment I have an insatiable appetite for all things ASP.NET MVC, which is what I've been using for a week or so now to (re)develop a couple of sites.
First off I practised by converting this site from "classic" WebForms and now I'm using MVC 3 and Linq-2-SQL on a real paid job. I have to say I completely love it. It's like I've discovered web development nirvana.
Anyway, what's this new way of learning? Well, it's a daily email from Stack Overflow. If you go to the page that show all tags you can subscribe to a daily email of those that are deemed new and interesting for any tag you fancy, like so:
You can also follow via RSS but that's too easy to ignore, whereas I like how I get a list in my inbox once a day:
All I do then is skim through and for any that sound of use I click to read the answers provided.
I've learnt quite a lot using this new approach so far...
Skip to the 
You can subscribe to an individual
I saw that to on SO, these guys are really quite savvy with the evolution of community managed knowledge.
Reply
Jake,
LINQ to SQL will not be developped anymore, and Microsoft is now concentrating on LINQ to Objects. Have a look at that! It's pretty cool and you can actually create objects that don't exactly fit your tables. As an example, you could have a "Invoice" object that would contain the "total" property even if it's not like that in the underlying tables.
: )
Reply
Thanks Benoit. Good to know.
I've been using the "repository interface pattern", so I should be shielded from too much re-working should the SQL side of LINQ die off? As I understand it.
I've been adding custom properties and methods to my SQL "objects" by using partial classes "based" upon what Linq-2-SQL creates. I'm guessing this is like your Invoice/total approach?
Reply
Show the rest of this thread
I think you are mistaking Linq-to-Objects (using Linq with Arrays, Lists, etc.) with Linq-to-Entities (the Entity Framework). Linq-to-Entities is what replaces Linq-to-SQL and, effectively, has more functionality and is an easy replacement for Linq-to-SQL (just creating an edmx that defines the same classes as the original dbml you can update the app without having to rewrite a single line of code).
That being said, Linq-to-Entities sucks incredibly if you try to access a database over which you have no control. We are on the third project where we have tried to use Linq-to-Entities and had to go back to Linq-to-SQL because we were accessing pre-existing databases which Linq-to-Entities didn't like.
P.S. You can create objects that don't map to your underlying classes in Linq-to-SQL (in fact, your example is quite simple to do!).
Reply
Show the rest of this thread