In the UK we are working with InnerWorkings to create a great offer of training to UK developers. We still have some stuff to sort out but I am hopeful that we will be able to share the details of this in the next few weeks. In my previous depth role we used InnerWorking successfully to help early adopters get up to speed with the core technologies which we then built on with our own labs, briefings and workshops. We were very impressed with the inventive format they use and the quality of the training. ......
One thing I like to get across when I talk about the ADO.NET Entity Framework is that in V1 the Designer does not support all the capabilities of the underlying Entity Data Model (EDM) – and hence you will sometimes need to “roll up your sleeves” and start editing the underlying XML files (CSDL, MSL, SSDL) that make up an EDM. There is a document which will help if you find yourself needing to do this - Entity Framework Supported Mapping Scenarios. Summary: This white paper enumerates the supported ......
This one has come up for both LINQ to SQL and LINQ to Entities. The scenario is a reasonably common one. How to handle something like this: CREATE PROCEDURE [dbo].[ReturnMultipleRS] AS select * from customers select * from products LINQ to SQL: The solution is to add a method to the DataContext using a partial class. Thankfully the Swiss MSDN team have already explained this one in great detail. Enjoy. LINQ to Entities: The easiest approach is to download the ADO.NET Entity Framework Extensions which ......
In October 2008 I summarised LINQ to SQL vs LINQ to Entities as: If you only care about SQL Server AND you have complete control of the “shape” of the db schema AND the application will live at most a few years, then LINQ to SQL is a good choice. LINQ to Entities would also work. If you have virtually no control of the “shape” of the db schema OR you are working against a RDBMS other than SQL Server OR you are building an application that will live many years, then LINQ to Entities is the best choice ......
I wanted a high level diagram which allowed me to talk about how the technologies worked together, worked apart, cover off areas such as multiple SSDLs, multiple EDMs etc. Not perfect – but proved useful ......
We have a rather impressive set of new technologies for working with data – LINQ, LINQ to SQL, LINQ to Entities, Data Services, ASP.NET Dynamic Data etc. What I am finding is… they don’t all get on with each other as well as you might have thought. My current battle is using ADO.NET Data Services with LINQ to SQL which is a) clearly something you might want to do and b) is something that isn’t going to work for you straight out of the box ......
What I wanted when I started out with LINQ was a “Query Analyser” for LINQ – rather than keep writing code inside Visual Studio. I can’t tell you how excited I was when I discovered LINQPad back in July 2008. It is written by Joseph Albahari who wrote C# 3.0 in a NutShell. It is an amazing tool – it does so much more than I expected and appears to be rock solid. Exactly what I was looking for. A big thanks to Joseph. Even better – no install needed! Dimecasts has two videos to help you get started: ......
The world of LINQ in a concept map ......
In my previous post I explained a little history of why this blog has come about – but now I wanted to explain why the heck you might read it :-) You should expect: Information on the very latest developer related technologies for building applications for Windows – client, server and cloud. A strong bias towards data - Object Relational Mapping, “Data in the Cloud”, Syncing data, RDBMS systems, N-tier data etc. Specifically I will be initially covering the ADO.NET Entity Framework, ADO.NET Data ......