A Possible Scenario for LINQ

[Bob Johnson]

Just wondering if LINQ might be useful and appropriate in the following
scenario:

I'm writing a Windows Forms app that enables the user to search for a
"client account". The client account is made up of a client number, plus a
case number. A given client can have many cases.
Here are two clients - the first of which has two cases.
1234-897
1234-989
7654-232

The application will encapsulate each client+case and related data in
separate objects (along with a list of financial transactions relevant to
the particular client+case). This class will have properties for client
number, case number, client name, and a List<Texposing the financial
transactions. DAL type methods will provide for saving changes to the DB
(SQL Server).

Here is where I'm thinking LINQ might come in: The user will need to search
for a specific client+case. The search could be by (1) client number, (2)
client+case number, or (3) client name.

During the search I'm not going to SQL for this data (so no LINK-to-sql).
The objects will loaded into memory during app startup; the search and UI
will then provide access to those in-memory objects.

Is the search functionality a good place to go with LINQ? Or should I go
with a List<Tand Predicate delegate.

I'm just starting the design of this, so I can do anything I want to do

I appreciate your opinions on this.

[Nicholas Paldino [.NET/C# MVP]]

Bob,

I think it is a good place to use LINQ. You could easily generate
queries which will search based on the properties of the object you want to
search on.

However, depending on how large the list is, you might want to try and
optimize your collections. For example, if you get a client number/case
number combo, you might want to have lists of case numbers that pertain to a
client stored in a hash table. That way, you can get the list of case
numbers easily for a particular client.

It's really a way if indexing, if you think about it, which you can
still use LINQ to help you out with.

If your client objects expose collections of cases, then that would make
it even easier, since you already have performed most of the grouping ahead
of time.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Bob Johnson" <[e-mail] in message
news:uM**************@TK2MSFTNGP02.phx.gbl...

Just wondering if LINQ might be useful and appropriate in the following
scenario:

I'm writing a Windows Forms app that enables the user to search for a
"client account". The client account is made up of a client number, plus a
case number. A given client can have many cases.
Here are two clients - the first of which has two cases.
1234-897
1234-989
7654-232

The application will encapsulate each client+case and related data in
separate objects (along with a list of financial transactions relevant to
the particular client+case). This class will have properties for client
number, case number, client name, and a List<Texposing the financial
transactions. DAL type methods will provide for saving changes to the DB
(SQL Server).

Here is where I'm thinking LINQ might come in: The user will need to
search for a specific client+case. The search could be by (1) client
number, (2) client+case number, or (3) client name.

During the search I'm not going to SQL for this data (so no LINK-to-sql).
The objects will loaded into memory during app startup; the search and UI
will then provide access to those in-memory objects.

Is the search functionality a good place to go with LINQ? Or should I go
with a List<Tand Predicate delegate.

I'm just starting the design of this, so I can do anything I want to do

I appreciate your opinions on this.