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 > > > > > > > > > >
