|
Ahh, I don't read a lot of your stuff. It's too sensitive and touchy-feely. 
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Oh well.
|
|
|
|
|
u seemed to be an early adopter
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Till fixed by EF Team, you can run a plain SQL from Entity Framework Core 2.0 and still map to your List<person> if I am right?
|
|
|
|
|
I'll have to check that out.
Don't know about it, but thanks for the tip 
|
|
|
|
|
|
Can't you achieve your goal like this?
var result = context.Persons
.Where(p=> !p.PersonLink.Any(pl=>p.Id == pl.PersonLinkId))
.Select(p => p.Name)
.OrderBy(n => n)
.Skip(a).Take(b).ToList();
from the moment you use a select your're requesting a projection.
Paulo Gomes
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
—Bill Gates
Everything should be made as simple as possible, but not simpler.
—Albert Einstein
|
|
|
|
|
Yeah, that might work.
I was thinking I could do a right join and select everything that can't be joined.
I guess this is the same, but different
Perhaps it's easier to just write some SQL for readability and clarity.
|
|
|
|
|
Stop using EF and just use SQL and a data access layer...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Steve Naidamast wrote: a data access layer
Like EF...? 
Ok, I know what you mean, but I'm not going back to writing weakly typed strings if I can have objects, strong types, intellisense and automatic mapping 
|
|
|
|
|
I understand your desire for strongly typed data upon the return of your queries. I prefer the same myself so what I do is after I have retrieved my data using a data access layer, I load the items into a structure object in the business-logic tier, which has all of the fields defined that I require and then return an array-list of such objects to my front-end.
I have been doing this for many years and have never had a problem with the technique.
Using an ORM is fine if it is actually needed such as for example, a new application that will require access to a very large, existing database. In this case you may want to opt for an ORM to get the structures of your data more quickly accessible to you.
However, ORMs tend to be on the "heavy" side in terms of tiers, making them somewhat inefficient.
In addition, using any ORM forces one to learn the idiosyncrasies of that ORM as well as the interface language. In EF's case, that would be LINQ, though you can also use EF-SQL. The result is that you become fluent in a single ORM instead of the more general language of standard SQL.
It is of course a matter of personal preference but I am one who does not like to stray too far from the basics since most of the many tools today are always in a state of flux, which can cause more problems than they are worth at times.
Just saying... 
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Steve Naidamast wrote: However, ORMs tend to be on the "heavy" side in terms of tiers, making them somewhat inefficient.
I'd gladly sacrifice some milliseconds for the days I save in development 
Steve Naidamast wrote: using any ORM forces one to learn the idiosyncrasies of that ORM as well as the interface language. In EF's case, that would be LINQ, though you can also use EF-SQL. The result is that you become fluent in a single ORM instead of the more general language of standard SQL.
I don't think you can be fluent in LINQ-to-Entities without being fluent in "bare" SQL as well.
Not being fluent in LINQ creates horrible SQL, which makes it a horrible LINQ query (no matter how "well" your LINQ query is written)
Learning how .NET translates LINQ to SQL took some time, but I thought I managed pretty well.
Until I found out EF Core doesn't support set operators that is 
I know what you mean though, and it's a shame that many developers are writing LINQ without knowing SQL.
I do keep my entities in its own data layer and only return "real" POCO's to my other layers though.
In theory, I could create a project, implement some interfaces, write a bunch of ADO.NET, and replace my entire EF with ADO.NET in a single project.
So you and I more or less do the same, but a little different
|
|
|
|
|
Okay, so do you know why some people call it the BLEEDING EDGE?
|
|
|
|
|
I do now 
|
|
|
|
|
EF supports stored procedures; that's what they're for.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Not bad, huh? Easy to remember
|
|
|
|
|
Too late 
|
|
|
|
|
What do you mean? Someone beat me to it? 
|
|
|
|
|
No, I meant too late for april's fool jokes 
|
|
|
|
|
Ah. 
|
|
|
|
|
privacy-first consumer
There's an oxymoron for you. 
|
|
|
|
|
Well, I think choice is good. So far it was just the Google DNS, now here's one more.
|
|
|
|
|
Nish Nishant wrote: So far it was just the Google DNS, now here's one more.
There is also Quad9[^] 9.9.9.9 which is a joint IBM,PCH and GCA project.
Best Wishes,
-David Delaune
|
|
|
|
|
Thank you.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
