Unfortunately I am implementing an interface that was designed up
stream, so I really can't change the design.
I was able to do a hybrid approach:
foreach (var user in userList)
{
if (user.RoleTypes.Intersect(RoleList).Count() > 0)
{
filteredUsers.Add(user);
}
}
Thanks for the feedback.
On Feb 3, 1:28 am, Joe Enos <[email protected]> wrote:
> Whenever I see roles like this, the first thing I think about is using
> bit logic - I've never actually implemented it, but I know it's a
> powerful technique - assigning powers of 2 to each role, then you can
> use bit functions to quickly determine whether or not a user has a
> specific role. Not really an answer to your question, but just a
> thought...
>
> Also, I could be wrong, but I think querying objects using Linq to
> objects provides no performance benefit versus doing the looping
> yourself - so there's no real benefit other than code style - unless
> you're planning on doing a lot of Linq in your project, my opinion is
> that good old-fashioned loops are easier to read and debug than a
> single implementation of a Linq function.
>
> On Feb 2, 2:43 pm, "[email protected]" <[email protected]>
> wrote:
>
> > I have a function that takes an array of integers(roles) and returns a
> > set of objects that contain one or more of the roles within a child
> > collection:
>
> > public Users[] GetUsersByRoles(int[] Roles)
> > {
>
> > }
>
> > public class Users
> > {
> > public int[] roles;
> > public string blah;
> > ...
>
> > }
>
> > If I pass 2,4,6 then I would return any users that has at least one of
> > the elements.
>
> > Is there any way that Linq to Objects can do the heavy lifting for
> > me? I would rather not have to loop through each user and query their
> > roles.
>
> > Thanks,
>
> > Brian
