"Luna" <l***@googlegroups.com> wrote in message
news:urH6gBCXJHA.5328@TK2MSFTNGP05.phx.gbl...
> How can I add additional where filters to a query via parameter input?
>
> filter = title == "data1"
>
> public IList<something> GetSomething(int id, Where filter)
> {
>     var a= from t in database.Test
>     where t.id = id && //insert more filter query here
>     select t;
>
>     return a
> }
>
> Luna

"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in
message news:ORyf1LHXJHA.5052@TK2MSFTNGP04.phx.gbl...
> Luna,
>
>    There are some errors here.  The first is that you shouldn't be
> returning IList<T> (you use "something" for T) from this method.  You are
> going to have an IEnumerable<something>, as you don't know what the query
> operators are going to be.
>
>    Additionally, the "where filter" will be in the form of a Predicate<T>.
> So your signature would look like this (replace T with the type of items
> returned from database.Test):
>
> public IEnumerable<T> GetSomething(int id, Predicate<T> filter)
> {
>    // Just return the items.
>    return database.Test.Where(t => t.id = id).Where(filter);
> }
>
>    I basically opted to use the extension methods instead of the query
> syntax, they are the same thing.
>
>    A big selling point of LINQ is the ability to compose queries, and you
> can do the same thing here.  It might be easier to just have GetSomething
> return the filter on id, and then attach the predicate later, so you would
> have:
>
> public IEnumerable<T> GetSomething(int id)
> {
>    // Just return the items filtered on id.
>    return database.Test.Where(t => t.id = id);
> }
>
>    And then when you call, have:
>
> IEnumerable<T> query = GetSomething(id).Where(filter);
>
>    Of course, one could argue that your query is simple enough that you
> don't really need a separate method for it, as it might convey your intent
> more clearly to have the entire query defined where you want to call it
> (instead of calling GetSomething, you just access database.Test).
>
>
> --
>          - Nicholas Paldino [.NET/C# MVP]
>          - mvp@spam.guard.caspershouse.com
>
>
> "Luna" <l***@googlegroups.com> wrote in message
> news:urH6gBCXJHA.5328@TK2MSFTNGP05.phx.gbl...
>> How can I add additional where filters to a query via parameter input?
>>
>> filter = title == "data1"
>>
>> public IList<something> GetSomething(int id, Where filter)
>> {
>>     var a= from t in database.Test
>>     where t.id = id && //insert more filter query here
>>     select t;
>>
>>     return a
>> }
>>
>> Luna
>
>

"Peter Duniho" <NpOeStPe***@nnowslpianmk.com> wrote in message
news:op.ul2749j28jd0ej@petes-computer.local...
> On Fri, 12 Dec 2008 21:36:45 -0800, Luna <l***@googlegroups.com> wrote:
>
>> Im new to LINQ, what's the difference between IList and IEnumerable they
>> seem to serve the same functions.
>
> Well, IList inherits IEnumerable.  So one is a superset of the other.
>
>> Also I've seen sample code where the return type is an array
>> (something[]) what's most efficient?
>
> It depends on how it's used.  There is no way to answer that question with
> some specific code example.
>
> Pete

"Peter Duniho" <NpOeStPe***@nnowslpianmk.com> wrote in message
news:op.ul4ds5jr8jd0ej@petes-computer.local...
> On Sat, 13 Dec 2008 12:52:35 -0800, Luna <l***@googlegroups.com> wrote:
>
>> So what added features does IList have over IEnumerable?
>
> MSDN has a comphrensive description of both.  I recommend that you read
> that.
>
>>> It depends on how it's used.  There is no way to answer that question
>>> with some specific code example.
>> Ill try to find that code example
>>
>> I think an array is faster than IList but is less flexible right?
>
> No, that is not right.  As I already wrote, without a code example, there
> is no way to answer the question.
>
> Of course, the fact that IList is an interface (something for which there
> are multiple implementations) and Array is a class (a specific
> implementation of the class and of several interfaces, including IList)
> also prevents an answer to the question.  But, even if you named a
> specific implementation of IList (e.g. List<T>) and compared that to
> Array, without knowing how they are used it's not possible to know which
> is "faster".
>
> (Unless of course you are comparing the Array implementation of IList to
> Array, in which case they are obviously exactly the same speed for
> identical operations).
>
> One very general comparison is to look at how often the collection needs
> to be modified and in what way.
>
> If you know in advance how large your collection is, and its size won't
> ever change, then Array is likely to be marginally faster (though, you can
> preallocate a List<T> and achieve nearly the same performance
> characteristics).  On the other hand, if your collection is going to be
> modified regularly, including insertions, additions, or removals, List<T>
> is going to be significantly faster than a naïve use of Array (though, you
> could of course use an Array exactly as a List<T> would use internally,
> thus achieving the same performance characteristics at the cost of more
> development work...why anyone would do that, I don't know).
>
> To reiterate: your question is unanswerable without some specific code
> example to reference.  The performance depends exactly on how the types
> are used and which types you are using.
>
> Finally, I will point out that you are probably asking the wrong question
> anyway.  You should be using the type that most closely matches your use
> of the data structure.  In most cases, good performance will come
> naturally as a result, while you are left to focus on what code best
> expresses your intent.  Worrying about which is "faster" before you have
> any evidence that the otherwise-preferred solution is "too slow" is a
> premature optimization and should be avoided.
>
> Pete