Single() shouldn't have to find all results, it just has to check if there is more than one.
On Mon, Aug 9, 2010 at 2:49 PM, Michael Minutillo <[email protected]> wrote: > First should be quicker than Single shouldn't it? First just has to find one > result. Single has to find all results and ensure there is only one. > > > Michael M. Minutillo > Indiscriminate Information Sponge > Blog: http://wolfbyte-net.blogspot.com > > > On Mon, Aug 9, 2010 at 12:10 PM, <[email protected]> wrote: >> >> 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 >> > >> > >> > >> >> >> > >
