Hi all, I have my archidev hat on at the moment (given my last few emails I'm betting that doesn't surprise people)
One task I have been looking at is figuring out how to convert our applications from Linq to SQL over to Linq to Entities. The reasons are that Linq to Entities is installed out-of-the-box, and Linq to SQL has to be added in (this implies a preference by Microsoft), LINQ to SQL is no longer receiving support from Microsoft, and LINQ to Entities supports multiple databases and devices. Apart from that, it provides much of the same; everything that Linq to SQL does, Linq to Entities can certainly do. But Linq to Entities gives me no other real advantages within my environment other than "architectural correctness" perhaps. But LINQ to SQL has one distinct advantage over Linq to Entities. This is the major major gripe that I have, and on this basis is enough for me to choose SQL over Entities. When I drag a stored procedure from the server explorer onto my linq to sql designer, the stored proc appears in the designer in a column on the right. If I have other objects on the designer, such as a table/entity, I can map the stored proc output to that object. It's all visual and I can see whether everthing has been done right. It's also simple for my developers to see whether they've provided everything they're meant to provide when returning data from the database. In the LINQ to Entities case, I drag a stored proc onto the designer. It _disappears_ into the ether. Yes, it was added, but there's nothing visual on the designer to tell me that. Not only that, but I have to _map_ the stored proc to a function by using a right-click context menu and performing a function import. After the function import, the routine is available to be called, but it still does not appear on the designer. I have to open the Model Browser to find my stored proc, and that's on a tab behind my solution explorer. So that, and that alone, is enough to make me reject LINQ to Entities. It is the pain of extra administration. And it shouldn't be that hard for the designer to be fixed to behave in a similar fashion to LINQ to SQL as well. There is nothing that says that it would be impossible for a stored procedure to be dragged onto the canvas and have the function imported immediately based on the stored procedure name, and have the stored procedure itself available via the properties of that function. So that's my gripe. Regards, Tony
