Yea but you could always use First, right? Single would only be fractionally faster, if at all, methinks..
On Mon, Aug 9th, 2010 at 1:30 PM, Michael Lyons <[email protected]> wrote: > I totally agree with you Tony. I've always felt the LINQ to SQL designer > was > somewhat more thought out and aimed at the whole KISS principle, while > LINQ > to Entities tried to be "enterprisey" when it really didn't need to be. > > Admittedly I haven't taken a look at EF since back when it first came > out, > with my biggest turn off being Single() / SingleOrDefault() missing. Has > this been added now? > > ------------- > Michael Lyons > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > On Behalf Of [email protected] > Sent: Monday, 9 August 2010 12:19 PM > To: [email protected] > Subject: I don't like Linq to Entities > > 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 > > >
