Mixing
Going from IQueryable<IEnumerable> to IEnumerable
4
$begingroup$
I have a "GetPersonsPerDepartment()" method returning a IQueryable<IEnumerable<Person>> while I'm trying to get a simple List<Person> or IEnumerable<Person> with all the persons from every department. I wrote a simple method GetAllPersons() that solves this with a loop but I feel I must be missing a simple command to get the same result:
private List<Person> GetAllPersons()
{
List<Person> allPersons = new List<Person>();
foreach(var Persons in GetPersonsPerDepartment())
{
allPersons.AddRange(Persons);
}
return allPersons;
}
private IQueryable<IEnumerable<Person>> GetPersonsPerDepartment()
{
IQueryable<IEnumerable<Person>> Persons;
using (var context = MySource.GetPersonsContext())
{
var library = "Personlist";
var PersonFolderList = context.Web.Lists.GetByTitle(library);
context.Load<List>(PersonFolderList);
var PersonFolderListItems = PersonFolderList.GetItems(new CamlQuery());
context.Load<ListItemCollection>(PersonFolderListItems);
context.ExecuteQuery();
Persons = PersonFolderListItems.Where(x => x.FileSystemObjectType == FileSystemObjectType.Folder).Select(x => GetPersonsFromFolderListItem(x, context, PersonFolderList));
}
return Persons;
}
c# beginner .net linq collections
edited Jan 10 at 18:59
t3chb0t
34.4k748118
asked Jan 10 at 13:19
user1073075user1073075
227128
$endgroup$
add a comment |
4
$begingroup$
I have a "GetPersonsPerDepartment()" method returning a IQueryable<IEnumerable<Person>> while I'm trying to get a simple List<Person> or IEnumerable<Person> with all the persons from every department. I wrote a simple method GetAllPersons() that solves this with a loop but I feel I must be missing a simple command to get the same result:
private List<Person> GetAllPersons()
{
List<Person> allPersons = new List<Person>();
foreach(var Persons in GetPersonsPerDepartment())
{
allPersons.AddRange(Persons);
}
return allPersons;
}
private IQueryable<IEnumerable<Person>> GetPersonsPerDepartment()
{
IQueryable<IEnumerable<Person>> Persons;
using (var context = MySource.GetPersonsContext())
{
var library = "Personlist";
var PersonFolderList = context.Web.Lists.GetByTitle(library);
context.Load<List>(PersonFolderList);
var PersonFolderListItems = PersonFolderList.GetItems(new CamlQuery());
context.Load<ListItemCollection>(PersonFolderListItems);
context.ExecuteQuery();
Persons = PersonFolderListItems.Where(x => x.FileSystemObjectType == FileSystemObjectType.Folder).Select(x => GetPersonsFromFolderListItem(x, context, PersonFolderList));
}
return Persons;
}
c# beginner .net linq collections
edited Jan 10 at 18:59
t3chb0t
34.4k748118
asked Jan 10 at 13:19
user1073075user1073075
227128
$endgroup$
add a comment |
4
4
4
$begingroup$
I have a "GetPersonsPerDepartment()" method returning a IQueryable<IEnumerable<Person>> while I'm trying to get a simple List<Person> or IEnumerable<Person> with all the persons from every department. I wrote a simple method GetAllPersons() that solves this with a loop but I feel I must be missing a simple command to get the same result:
private List<Person> GetAllPersons()
{
List<Person> allPersons = new List<Person>();
foreach(var Persons in GetPersonsPerDepartment())
{
allPersons.AddRange(Persons);
}
return allPersons;
}
private IQueryable<IEnumerable<Person>> GetPersonsPerDepartment()
{
IQueryable<IEnumerable<Person>> Persons;
using (var context = MySource.GetPersonsContext())
{
var library = "Personlist";
var PersonFolderList = context.Web.Lists.GetByTitle(library);
context.Load<List>(PersonFolderList);
var PersonFolderListItems = PersonFolderList.GetItems(new CamlQuery());
context.Load<ListItemCollection>(PersonFolderListItems);
context.ExecuteQuery();
Persons = PersonFolderListItems.Where(x => x.FileSystemObjectType == FileSystemObjectType.Folder).Select(x => GetPersonsFromFolderListItem(x, context, PersonFolderList));
}
return Persons;
}
c# beginner .net linq collections
edited Jan 10 at 18:59
t3chb0t
34.4k748118
asked Jan 10 at 13:19
user1073075user1073075
227128
$endgroup$
I have a "GetPersonsPerDepartment()" method returning a IQueryable<IEnumerable<Person>> while I'm trying to get a simple List<Person> or IEnumerable<Person> with all the persons from every department. I wrote a simple method GetAllPersons() that solves this with a loop but I feel I must be missing a simple command to get the same result:
private List<Person> GetAllPersons()
{
List<Person> allPersons = new List<Person>();
foreach(var Persons in GetPersonsPerDepartment())
{
allPersons.AddRange(Persons);
}
return allPersons;
}
private IQueryable<IEnumerable<Person>> GetPersonsPerDepartment()
{
IQueryable<IEnumerable<Person>> Persons;
using (var context = MySource.GetPersonsContext())
{
var library = "Personlist";
var PersonFolderList = context.Web.Lists.GetByTitle(library);
context.Load<List>(PersonFolderList);
var PersonFolderListItems = PersonFolderList.GetItems(new CamlQuery());
context.Load<ListItemCollection>(PersonFolderListItems);
context.ExecuteQuery();
Persons = PersonFolderListItems.Where(x => x.FileSystemObjectType == FileSystemObjectType.Folder).Select(x => GetPersonsFromFolderListItem(x, context, PersonFolderList));
}
return Persons;
}
c# beginner .net linq collections
c# beginner .net linq collections
edited Jan 10 at 18:59
t3chb0t
34.4k748118
asked Jan 10 at 13:19
user1073075user1073075
227128
edited Jan 10 at 18:59
t3chb0t
34.4k748118
asked Jan 10 at 13:19
user1073075user1073075
227128
edited Jan 10 at 18:59
t3chb0t
34.4k748118
edited Jan 10 at 18:59
t3chb0t
34.4k748118
edited Jan 10 at 18:59
t3chb0t
34.4k748118
34.4k748118
asked Jan 10 at 13:19
user1073075user1073075
227128
asked Jan 10 at 13:19
user1073075user1073075
227128
asked Jan 10 at 13:19
user1073075user1073075
227128
227128
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
22
$begingroup$
Use SelectMany. As in, allPersons.SelectMany(s => s);. This flattens the sequence for you.
answered Jan 10 at 13:24
Hosch250Hosch250
17.6k567159
$endgroup$
11
$begingroup$
Not only one-liner code but also a one-liner review - there should be a badge for it ;-]
$endgroup$
– t3chb0t
Jan 10 at 13:28
4
$begingroup$
There seems to be :). The +10 answer badge.
$endgroup$
– Hosch250
Jan 10 at 15:48
1
$begingroup$
While correct, I findSelectMany(s => s)does not really convey the "concatenate all of these together" meaning very well. If you're not a heavy LINQ user, it's going to confuse you initially. (I've had coworkers be confused by it.) One might consider wrapping this inside a method:public static ConcatAll<T>(this IEnumerable<IEnumerable<T>> e) { return e.SelectMany(i = i); }.
$endgroup$
– jpmc26
Jan 11 at 2:03
1
$begingroup$
@jpmc26 I've had coworkers be confused by it - then they either should learn how to use LINQ correctly or leave writing software to people who can understand something as simple asSelectMany.. Creating extensions likeConcatAllis even more confusing.
$endgroup$
– t3chb0t
Jan 12 at 14:30
$begingroup$
@t3chb0t Giving things appropriate, straightforward names that clearly communicates their behavior increases confusion? Wat. The best kind of code is code that can be understood at a glance. There is absolutely nothing wrong with being clear enough that other people understand something immediately. Honestly, we'd all be better off if the .NET standard library was written with that mindset. How did you get 34k rep on a code review site thinking like that?
$endgroup$
– jpmc26
Jan 12 at 17:54
add a comment |
3
$begingroup$
Is this a bug or dirty workaround?
There is one thing in your code that sooner or later will bite you and I don't quite understnd why it didn't...
You're returing an IQueryable<IEnumerable<Person>> after you have disposed your context. I'm not sure what workarounds your are using there because you provided very little context but your code actually shouldn't work.
I suppose it's Entity Framework and with it you should never return IQuerybale if you're disposing its context by the same method but always materialize the query before returnig the result, e.g. with ToList etc.
answered Jan 10 at 18:52
t3chb0tt3chb0t
34.4k748118
$endgroup$
$begingroup$
Returning anIQueryableis a perfectly valid strategy with EF--it won't actually do the query until you materialize it, and it allows other parts of the code to add additional filters/tranformations to the data that will be executed on the DB, making it more performant. Of course, this only works in certain cases where you get the context when you need it, instead of being in ausingblock (like if you are working from anIGenericRepositorytype thing).
$endgroup$
– Hosch250
Jan 10 at 19:29
2
$begingroup$
@Hosch250 I know how it works and clarified what I meant ;-] OP does have ausingblock here thus it's super confusing why it actually works... it shouldn't and IMO there is some dirty workaround becuase if it's materialized then it shouldn't be anIQueryableand if it's not then the context should not be disposed.
$endgroup$
– t3chb0t
Jan 10 at 19:34
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f211258%2fgoing-from-iqueryableienumerablemyobj-to-ienumerablemyobj%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
22
$begingroup$
Use SelectMany. As in, allPersons.SelectMany(s => s);. This flattens the sequence for you.
answered Jan 10 at 13:24
Hosch250Hosch250
17.6k567159
$endgroup$
11
$begingroup$
Not only one-liner code but also a one-liner review - there should be a badge for it ;-]
$endgroup$
– t3chb0t
Jan 10 at 13:28
4
$begingroup$
There seems to be :). The +10 answer badge.
$endgroup$
– Hosch250
Jan 10 at 15:48
1
$begingroup$
While correct, I findSelectMany(s => s)does not really convey the "concatenate all of these together" meaning very well. If you're not a heavy LINQ user, it's going to confuse you initially. (I've had coworkers be confused by it.) One might consider wrapping this inside a method:public static ConcatAll<T>(this IEnumerable<IEnumerable<T>> e) { return e.SelectMany(i = i); }.
$endgroup$
– jpmc26
Jan 11 at 2:03
1
$begingroup$
@jpmc26 I've had coworkers be confused by it - then they either should learn how to use LINQ correctly or leave writing software to people who can understand something as simple asSelectMany.. Creating extensions likeConcatAllis even more confusing.
$endgroup$
– t3chb0t
Jan 12 at 14:30
$begingroup$
@t3chb0t Giving things appropriate, straightforward names that clearly communicates their behavior increases confusion? Wat. The best kind of code is code that can be understood at a glance. There is absolutely nothing wrong with being clear enough that other people understand something immediately. Honestly, we'd all be better off if the .NET standard library was written with that mindset. How did you get 34k rep on a code review site thinking like that?
$endgroup$
– jpmc26
Jan 12 at 17:54
add a comment |
22
$begingroup$
Use SelectMany. As in, allPersons.SelectMany(s => s);. This flattens the sequence for you.
answered Jan 10 at 13:24
Hosch250Hosch250
17.6k567159
$endgroup$
11
$begingroup$
Not only one-liner code but also a one-liner review - there should be a badge for it ;-]
$endgroup$
– t3chb0t
Jan 10 at 13:28
4
$begingroup$
There seems to be :). The +10 answer badge.
$endgroup$
– Hosch250
Jan 10 at 15:48
1
$begingroup$
While correct, I findSelectMany(s => s)does not really convey the "concatenate all of these together" meaning very well. If you're not a heavy LINQ user, it's going to confuse you initially. (I've had coworkers be confused by it.) One might consider wrapping this inside a method:public static ConcatAll<T>(this IEnumerable<IEnumerable<T>> e) { return e.SelectMany(i = i); }.
$endgroup$
– jpmc26
Jan 11 at 2:03
1
$begingroup$
@jpmc26 I've had coworkers be confused by it - then they either should learn how to use LINQ correctly or leave writing software to people who can understand something as simple asSelectMany.. Creating extensions likeConcatAllis even more confusing.
$endgroup$
– t3chb0t
Jan 12 at 14:30
$begingroup$
@t3chb0t Giving things appropriate, straightforward names that clearly communicates their behavior increases confusion? Wat. The best kind of code is code that can be understood at a glance. There is absolutely nothing wrong with being clear enough that other people understand something immediately. Honestly, we'd all be better off if the .NET standard library was written with that mindset. How did you get 34k rep on a code review site thinking like that?
$endgroup$
– jpmc26
Jan 12 at 17:54
add a comment |
22
22
22
$begingroup$
Use SelectMany. As in, allPersons.SelectMany(s => s);. This flattens the sequence for you.
answered Jan 10 at 13:24
Hosch250Hosch250
17.6k567159
$endgroup$
Use SelectMany. As in, allPersons.SelectMany(s => s);. This flattens the sequence for you.
answered Jan 10 at 13:24
Hosch250Hosch250
17.6k567159
answered Jan 10 at 13:24
Hosch250Hosch250
17.6k567159
answered Jan 10 at 13:24
Hosch250Hosch250
17.6k567159
answered Jan 10 at 13:24
Hosch250Hosch250
17.6k567159
17.6k567159
11
$begingroup$
Not only one-liner code but also a one-liner review - there should be a badge for it ;-]
$endgroup$
– t3chb0t
Jan 10 at 13:28
4
$begingroup$
There seems to be :). The +10 answer badge.
$endgroup$
– Hosch250
Jan 10 at 15:48
1
$begingroup$
While correct, I findSelectMany(s => s)does not really convey the "concatenate all of these together" meaning very well. If you're not a heavy LINQ user, it's going to confuse you initially. (I've had coworkers be confused by it.) One might consider wrapping this inside a method:public static ConcatAll<T>(this IEnumerable<IEnumerable<T>> e) { return e.SelectMany(i = i); }.
$endgroup$
– jpmc26
Jan 11 at 2:03
1
$begingroup$
@jpmc26 I've had coworkers be confused by it - then they either should learn how to use LINQ correctly or leave writing software to people who can understand something as simple asSelectMany.. Creating extensions likeConcatAllis even more confusing.
$endgroup$
– t3chb0t
Jan 12 at 14:30
$begingroup$
@t3chb0t Giving things appropriate, straightforward names that clearly communicates their behavior increases confusion? Wat. The best kind of code is code that can be understood at a glance. There is absolutely nothing wrong with being clear enough that other people understand something immediately. Honestly, we'd all be better off if the .NET standard library was written with that mindset. How did you get 34k rep on a code review site thinking like that?
$endgroup$
– jpmc26
Jan 12 at 17:54
add a comment |
11
$begingroup$
Not only one-liner code but also a one-liner review - there should be a badge for it ;-]
$endgroup$
– t3chb0t
Jan 10 at 13:28
4
$begingroup$
There seems to be :). The +10 answer badge.
$endgroup$
– Hosch250
Jan 10 at 15:48
1
$begingroup$
While correct, I findSelectMany(s => s)does not really convey the "concatenate all of these together" meaning very well. If you're not a heavy LINQ user, it's going to confuse you initially. (I've had coworkers be confused by it.) One might consider wrapping this inside a method:public static ConcatAll<T>(this IEnumerable<IEnumerable<T>> e) { return e.SelectMany(i = i); }.
$endgroup$
– jpmc26
Jan 11 at 2:03
1
$begingroup$
@jpmc26 I've had coworkers be confused by it - then they either should learn how to use LINQ correctly or leave writing software to people who can understand something as simple asSelectMany.. Creating extensions likeConcatAllis even more confusing.
$endgroup$
– t3chb0t
Jan 12 at 14:30
$begingroup$
@t3chb0t Giving things appropriate, straightforward names that clearly communicates their behavior increases confusion? Wat. The best kind of code is code that can be understood at a glance. There is absolutely nothing wrong with being clear enough that other people understand something immediately. Honestly, we'd all be better off if the .NET standard library was written with that mindset. How did you get 34k rep on a code review site thinking like that?
$endgroup$
– jpmc26
Jan 12 at 17:54
11
11
$begingroup$
Not only one-liner code but also a one-liner review - there should be a badge for it ;-]
$endgroup$
– t3chb0t
Jan 10 at 13:28
$begingroup$
Not only one-liner code but also a one-liner review - there should be a badge for it ;-]
$endgroup$
– t3chb0t
Jan 10 at 13:28
4
4
$begingroup$
There seems to be :). The +10 answer badge.
$endgroup$
– Hosch250
Jan 10 at 15:48
$begingroup$
There seems to be :). The +10 answer badge.
$endgroup$
– Hosch250
Jan 10 at 15:48
1
1
$begingroup$
While correct, I find
SelectMany(s => s) does not really convey the "concatenate all of these together" meaning very well. If you're not a heavy LINQ user, it's going to confuse you initially. (I've had coworkers be confused by it.) One might consider wrapping this inside a method: public static ConcatAll<T>(this IEnumerable<IEnumerable<T>> e) { return e.SelectMany(i = i); }.$endgroup$
– jpmc26
Jan 11 at 2:03
$begingroup$
While correct, I find
SelectMany(s => s) does not really convey the "concatenate all of these together" meaning very well. If you're not a heavy LINQ user, it's going to confuse you initially. (I've had coworkers be confused by it.) One might consider wrapping this inside a method: public static ConcatAll<T>(this IEnumerable<IEnumerable<T>> e) { return e.SelectMany(i = i); }.$endgroup$
– jpmc26
Jan 11 at 2:03
1
1
$begingroup$
@jpmc26 I've had coworkers be confused by it - then they either should learn how to use LINQ correctly or leave writing software to people who can understand something as simple as
SelectMany.. Creating extensions like ConcatAll is even more confusing.$endgroup$
– t3chb0t
Jan 12 at 14:30
$begingroup$
@jpmc26 I've had coworkers be confused by it - then they either should learn how to use LINQ correctly or leave writing software to people who can understand something as simple as
SelectMany.. Creating extensions like ConcatAll is even more confusing.$endgroup$
– t3chb0t
Jan 12 at 14:30
$begingroup$
@t3chb0t Giving things appropriate, straightforward names that clearly communicates their behavior increases confusion? Wat. The best kind of code is code that can be understood at a glance. There is absolutely nothing wrong with being clear enough that other people understand something immediately. Honestly, we'd all be better off if the .NET standard library was written with that mindset. How did you get 34k rep on a code review site thinking like that?
$endgroup$
– jpmc26
Jan 12 at 17:54
$begingroup$
@t3chb0t Giving things appropriate, straightforward names that clearly communicates their behavior increases confusion? Wat. The best kind of code is code that can be understood at a glance. There is absolutely nothing wrong with being clear enough that other people understand something immediately. Honestly, we'd all be better off if the .NET standard library was written with that mindset. How did you get 34k rep on a code review site thinking like that?
$endgroup$
– jpmc26
Jan 12 at 17:54
add a comment |
3
$begingroup$
Is this a bug or dirty workaround?
There is one thing in your code that sooner or later will bite you and I don't quite understnd why it didn't...
You're returing an IQueryable<IEnumerable<Person>> after you have disposed your context. I'm not sure what workarounds your are using there because you provided very little context but your code actually shouldn't work.
I suppose it's Entity Framework and with it you should never return IQuerybale if you're disposing its context by the same method but always materialize the query before returnig the result, e.g. with ToList etc.
answered Jan 10 at 18:52
t3chb0tt3chb0t
34.4k748118
$endgroup$
$begingroup$
Returning anIQueryableis a perfectly valid strategy with EF--it won't actually do the query until you materialize it, and it allows other parts of the code to add additional filters/tranformations to the data that will be executed on the DB, making it more performant. Of course, this only works in certain cases where you get the context when you need it, instead of being in ausingblock (like if you are working from anIGenericRepositorytype thing).
$endgroup$
– Hosch250
Jan 10 at 19:29
2
$begingroup$
@Hosch250 I know how it works and clarified what I meant ;-] OP does have ausingblock here thus it's super confusing why it actually works... it shouldn't and IMO there is some dirty workaround becuase if it's materialized then it shouldn't be anIQueryableand if it's not then the context should not be disposed.
$endgroup$
– t3chb0t
Jan 10 at 19:34
add a comment |
3
$begingroup$
Is this a bug or dirty workaround?
There is one thing in your code that sooner or later will bite you and I don't quite understnd why it didn't...
You're returing an IQueryable<IEnumerable<Person>> after you have disposed your context. I'm not sure what workarounds your are using there because you provided very little context but your code actually shouldn't work.
I suppose it's Entity Framework and with it you should never return IQuerybale if you're disposing its context by the same method but always materialize the query before returnig the result, e.g. with ToList etc.
answered Jan 10 at 18:52
t3chb0tt3chb0t
34.4k748118
$endgroup$
$begingroup$
Returning anIQueryableis a perfectly valid strategy with EF--it won't actually do the query until you materialize it, and it allows other parts of the code to add additional filters/tranformations to the data that will be executed on the DB, making it more performant. Of course, this only works in certain cases where you get the context when you need it, instead of being in ausingblock (like if you are working from anIGenericRepositorytype thing).
$endgroup$
– Hosch250
Jan 10 at 19:29
2
$begingroup$
@Hosch250 I know how it works and clarified what I meant ;-] OP does have ausingblock here thus it's super confusing why it actually works... it shouldn't and IMO there is some dirty workaround becuase if it's materialized then it shouldn't be anIQueryableand if it's not then the context should not be disposed.
$endgroup$
– t3chb0t
Jan 10 at 19:34
add a comment |
3
3
3
$begingroup$
Is this a bug or dirty workaround?
There is one thing in your code that sooner or later will bite you and I don't quite understnd why it didn't...
You're returing an IQueryable<IEnumerable<Person>> after you have disposed your context. I'm not sure what workarounds your are using there because you provided very little context but your code actually shouldn't work.
I suppose it's Entity Framework and with it you should never return IQuerybale if you're disposing its context by the same method but always materialize the query before returnig the result, e.g. with ToList etc.
answered Jan 10 at 18:52
t3chb0tt3chb0t
34.4k748118
$endgroup$
Is this a bug or dirty workaround?
There is one thing in your code that sooner or later will bite you and I don't quite understnd why it didn't...
You're returing an IQueryable<IEnumerable<Person>> after you have disposed your context. I'm not sure what workarounds your are using there because you provided very little context but your code actually shouldn't work.
I suppose it's Entity Framework and with it you should never return IQuerybale if you're disposing its context by the same method but always materialize the query before returnig the result, e.g. with ToList etc.
answered Jan 10 at 18:52
t3chb0tt3chb0t
34.4k748118
edited Jan 10 at 19:34
answered Jan 10 at 18:52
t3chb0tt3chb0t
34.4k748118
answered Jan 10 at 18:52
t3chb0tt3chb0t
34.4k748118
answered Jan 10 at 18:52
t3chb0tt3chb0t
34.4k748118
34.4k748118
$begingroup$
Returning anIQueryableis a perfectly valid strategy with EF--it won't actually do the query until you materialize it, and it allows other parts of the code to add additional filters/tranformations to the data that will be executed on the DB, making it more performant. Of course, this only works in certain cases where you get the context when you need it, instead of being in ausingblock (like if you are working from anIGenericRepositorytype thing).
$endgroup$
– Hosch250
Jan 10 at 19:29
2
$begingroup$
@Hosch250 I know how it works and clarified what I meant ;-] OP does have ausingblock here thus it's super confusing why it actually works... it shouldn't and IMO there is some dirty workaround becuase if it's materialized then it shouldn't be anIQueryableand if it's not then the context should not be disposed.
$endgroup$
– t3chb0t
Jan 10 at 19:34
add a comment |
$begingroup$
Returning anIQueryableis a perfectly valid strategy with EF--it won't actually do the query until you materialize it, and it allows other parts of the code to add additional filters/tranformations to the data that will be executed on the DB, making it more performant. Of course, this only works in certain cases where you get the context when you need it, instead of being in ausingblock (like if you are working from anIGenericRepositorytype thing).
$endgroup$
– Hosch250
Jan 10 at 19:29
2
$begingroup$
@Hosch250 I know how it works and clarified what I meant ;-] OP does have ausingblock here thus it's super confusing why it actually works... it shouldn't and IMO there is some dirty workaround becuase if it's materialized then it shouldn't be anIQueryableand if it's not then the context should not be disposed.
$endgroup$
– t3chb0t
Jan 10 at 19:34
$begingroup$
Returning an
IQueryable is a perfectly valid strategy with EF--it won't actually do the query until you materialize it, and it allows other parts of the code to add additional filters/tranformations to the data that will be executed on the DB, making it more performant. Of course, this only works in certain cases where you get the context when you need it, instead of being in a using block (like if you are working from an IGenericRepository type thing).$endgroup$
– Hosch250
Jan 10 at 19:29
$begingroup$
Returning an
IQueryable is a perfectly valid strategy with EF--it won't actually do the query until you materialize it, and it allows other parts of the code to add additional filters/tranformations to the data that will be executed on the DB, making it more performant. Of course, this only works in certain cases where you get the context when you need it, instead of being in a using block (like if you are working from an IGenericRepository type thing).$endgroup$
– Hosch250
Jan 10 at 19:29
2
2
$begingroup$
@Hosch250 I know how it works and clarified what I meant ;-] OP does have a
using block here thus it's super confusing why it actually works... it shouldn't and IMO there is some dirty workaround becuase if it's materialized then it shouldn't be an IQueryable and if it's not then the context should not be disposed.$endgroup$
– t3chb0t
Jan 10 at 19:34
$begingroup$
@Hosch250 I know how it works and clarified what I meant ;-] OP does have a
using block here thus it's super confusing why it actually works... it shouldn't and IMO there is some dirty workaround becuase if it's materialized then it shouldn't be an IQueryable and if it's not then the context should not be disposed.$endgroup$
– t3chb0t
Jan 10 at 19:34
add a comment |
draft saved
draft discarded
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f211258%2fgoing-from-iqueryableienumerablemyobj-to-ienumerablemyobj%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
