1 - LINQ is probably resume fodder, and will most likely be used for all sorts of things it's not good for, before things settle down and it just becomes a tool in the toolbox.
2 - I can't percieve of a project NEEDING LINQ. It's just syntactic sugar. There are good reasons not to use it ( one, if you're the only one on a team who can read the code ). But, I still am trying to carve out time to know it better and to be able to use it myself.
Please read this if you don't understand the answer I've given you. If you're still stuck, ask me for more information.
For the most part, I agree with what Christian said.
1. LINQ is still very new and all of the guidance around when it should be used isn't in place yet. There is a lot of power and flexibility behind LINQ and the concepts taht are in place to support it, like extension methods and lambda expressions. Most of those language features will eventually just become another tool, in the same way foreach has.
2. There will never be a project that requires LINQ. Everything that can be accomplished using LINQ can be accomplished in more traditional manners as well, although it may be easier using LINQ or some of the LINQ related language features.
In my opinion, you're better off knowing how the supporting language features work (extension methods, lambdas, inferred typing, and object initializers) and what you can do with them. LINQ is a pretty big topic (LINQ to SQL, Entities, XML, etc...) but the supporting features are all the same no matter what.
The CallLogMethod still evaluates the condition, but it gets passed in. This is similar to how Debug.WriteLineIf works.
In either case, I would go with option 2 or 3 and push the test into the method itself. This way, you guarantee that it will always be tested and tested the same way and it's one less thing to worry about at the calling site.
I'm working in an ASP .NET project and in that I need to generate a unique key which is to be used instead of the primary key in the database of 6 digits and it should be random in nature yet it should be unique ofcourse. Actually the client doesnt want to issue numbers such as 000001, 000002... he wants it to be like 872731. The problem in my mind is that how are we gonna generate these unique but random numbers, coz whats bugging me is: WE would have to check for the keys already taken and 1) its v inefficient and 2) it could have problems with concurrency.
So I really need to guidelines from you people, I would definately appreciate this. Thank you.
Success is a ladder which you can't climb with your hands in your pockets.
You will likely need to persist all the id's in a table, then just create random number, check for uniqueness on table, repeat if necessary, add newly created number. For concurrency, you will probably need to lock the table or something.
It will only lock the table while generating the number, that should take 10ms, so that should work unless you need to do this 100 times a seconds. And in that case 6 digits wont cover uniqueness, you will run out in 10 minutes. That's why it is an anti-pattern (just wrong from the start).