We Keep Coding

Why do I need LINQ if I use NHibernate-like ORMs?

I was reading this SO question but still I am not clear about one specific thing.
If I use NHibernate, why do I need LINQ?
The question in my mind becomes more aggravated when I knew that NHibernate also included LINQ support.
LINQ to NHibernate?
WTF!

LINQ is a query language. It allows you to express queries in a way that is not tied in to your persistence layer.
You may be thinking about the LINQ 2 SQL ORM.
Using LINQ in naming the two is causes unfortunate confusions like yours.
nHibernate, EF, LINQ2XML are all LINQ providers - they all allow you to query a data source using the LINQ syntax.

Well, you don't need Linq, you can always do without it, but you might want it.
Linq provides a way to express operations that behave on sets of data that can be queried and where we can then perform other operations based on the state of that data. It's deliberately written so as to be as agnostic as possible whether that data is in-memory collections, XML, database, etc. Ultimately it's always operating on some sort of in-memory object, with some means of converting between in-memory and the ultimate source, though some bindings go further than others in pushing some of the operations down to a different layer. E.g. calling .Count() can end up looking at a Count property, spinning through a collection and keeping a tally, sending a Count(*) query to a database or maybe something else.
ORMs provide a way to have in-memory objects and database rows reflect each other, with changes to one being reflected by changes to the other.
That fits nicely into the "some means of converting" bit above. Hence Linq2SQL, EF and Linq2NHibernate all fulfil both the ORM role and the Linq provider role.
Considering that Linq can work on collections you'd have to be pretty perverse to create an ORM that couldn't support Linq at all (you'd have to design your collections to not implement IEnumerable<T> and hence not work with foreach). More directly supporting it though means you can offer better support. At the very least it should make for more efficient queries. For example if an ORM gave us a means to get a Users object that reflected all rows in a users table, then we would always be able to do:
int uID = (from u in Users where u.Username == "Alice" select u.ID).FirstOrDefault();
Without direct support for Linq by making Users implement IQueryable<User>, then this would become:
SELECT * FROM Users
Followed by:
while(dataReader.Read())
yield return ConstructUser(dataReader);
Followed by:
foreach(var user in Users)
if(user.Username == "Alice")
return user.ID;
return 0;
Actually, it'd be just slightly worse than that. With direct support the SQL query produced would be:
SELECT TOP 1 id FROM Users WHERE username = 'Alice'
Then the C# becomes equivalent to
return dataReader.Read() ? dataReader.GetInt32(0) : 0;
It should be pretty clear how the greater built-in Linq support of a Linq provider should lead to better operation.
Linq is an in-language feature of C# and VB.NET and can also be used by any .NET language though not always with that same in-language syntax. As such, ever .NET developer should know it, and every C# and VB.NET developer should particularly know it (or they don't know C# or VB.NET) and that's the group NHibernate is designed to be used by, so they can depend on not needing to explain a whole bunch of operations by just implementing them the Linq way. Not supporting it in a .NET library that represents queryable data should be considered a lack of completeness at best; the whole point of an ORM is to make manipulating a database as close to non-DB related operations in the programming language in use, as possible. In .NET that means Linq supprt.

First of all LINQ alone is not an ORM. It is a DSL to query the objects irrespective of the source it came from.
So it makes perfect sense that you can use LINQ with Nhibernate too
I believe you misunderstood the LINQ to SQL with plain LINQ.

Common sense?
There is a difference between an ORM like NHibernate and compiler integrated way to express queries which is use full in many more scenarios.
Or: Usage of LINQ (not LINQ to SQL etc. - the langauge, which is what you talk about though I am not sure you meant what you said) means you dont have to deal with Nhibernate special query syntax.
Or: Anyone NOT using LINQ - regardless of NHibernate or not - de qualifies without good explanation.

You don't need it, but you might find it useful. Bear in mind that Linq, as others have said, is not the same thing as Linq to SQL. Where I work, we write our own SQL queries to retrieve data, but it's quite common for us to use Linq to manipulate that data in order to serve a specific need. For instance, you might have a data access method that allows you to retrieve all dogs owned by Dave:
new DogOwnerDal().GetForOwner(id);
If you're only interested in Dave's daschunds for one specific need, and performance isn't that much of an issue, you can use Linq to filter the response for all of Dave's dogs down to the specific data that you need:
new DogOwnerDal().GetForOwner(id).Where(d => d.Breed == DogBreeds.Daschund);
If performance was crucial, you might want to write a specific data access method to retrieve dogs by owner and breed, but in many cases the effort expended to create the new data access method doesn't increase efficiency enough to be worth doing.
In your example, you might want to use NHibernate to retrieve a lump of data, and then use Linq to break that data into lots of individual subsets for some form of processing. It might well be cheaper to get the data once and use Linq to split it up, instead of repeatedly interrogating the database for different mixtures of the same data.

ADO.NET or Linq to SQL?

I am building a forum, and it has got 4 tables: Users, Threads, Comments, Topics.
I established the connection and the pages.. I started using the ADO.net way to insert data and select data..but then I found that to make more complex manipulations i need to know SQL. So I was looking for another way, and I found that I can open Visual Studio 2010, add Linq to SQL file that produced object relational designer. I read about how to write code, and I saw that I simply need to use a using statement with DataContext object with a simple code to update, add, delete rows in the tables.
I wanted to know, what are the advantages of using one way of querying over another?

ADO.NET gives you low level control over your queries. If query speed is going to be of importance, this is where you want to be. If you speed is not very important, but rapid development and an Object Relational Model is, LINQ to SQL is a safe bet.
I would recommend Linq to SQL over ADO.NET though.
Development is rapid and thinking in an ORM way is natural.
If your queries are too slow, using the .ExecuteQuery method will allow you to pass in a sql statement that you have optimized as if you were doing it in the ADO.NET way. I have had much success with Linq to Sql.
Also I would look at Entity Framework. It gives you more control over your objects and how they are implemented, used and handled than Linq.

LINQ to SQL is part of the ADO.NET family of technologies. It is based on services provided by the ADO.NET provider model. You can therefore mix LINQ to SQL code with existing ADO.NET applications and migrate current ADO.NET solutions to LINQ to SQL. The following illustration provides a high-level view of the relationship.
Refer to the following:
ADO.NET and LINQ to SQL
Advantages & Disadvantages of LINQ
Performance of LINQ to SQL over Normal Stored procedure
LINQ-to-SQL and Stored Procedures

LINQ to SQL is great in that it generates alot of the plumbing code for you. But it is basically the same as using straight up ADO.NET/SQL. To do more complex data manipulation in LINQ to SQL you have to know how write complex joins in LINQ just as you would in SQL.
Look into Entity Framework - it might give you a higher level of abstraction that you are looking for.

The two are on different abstraction levels. ADO.NET is the lowest level of data access in .NET. Anything else will build upon it.
Every abstraction should give you power to express higher-level concepts at the cost of lower level concepts.
If I sound like a philosopher it's because it's Friday.

In addition to Entity Framework, you can take a look at NHibernate (another .net Object Relational Mapper). It's been around longer than EF so it's a bit more mature, but it isn't developed by Microsoft if that matters to you.

Do SQL Queries Need to be that Complicated?

An open-ended question which may not have a "right" answer, but expert input on this would be appreciated.
Do SQL Queries Need to be that Complicated?
From a Web Dev point of view, as C#/.Net progresses, it seems that there are plenty of easy ways (LINQ, Generics) to do a lot of the things that some people tend to do in their SQL queries (sorting, ordering, merging, etc). That being said, since SQL tends to be the processing "bottleneck" for a lot of apps, a lot of the logic for SQL queries is being moved to the business layer.
As this trend continues, I'm seeing less of a need for large SQL queries.
What do you all think? Are you still writing large SQL queries? If so, is it because you need to or because you are more comfortable doing so than working in the business layer?

What's a "large" query?
The "bottleneck" encountered IME is typically because the tables were modeled poorly, compounded by someone constructing SQL queries that has little to no experience with SQL (the most common issue being thinking SQL is procedural when it's actually SET based). Lack of indexing is the next most common issue.
ORM has evolved to support native queries -- clear recognition that ORM simplifies database interaction, but can't perform as well as proper SQL query development.
Keeping the persistence handling in the business layer is justified by desiring database independence (at the risk of performance). Otherwise, it's a waste of money and resources to ignore what the database can handle in far larger loads, in a central location (that can be clustered).

It depends entirely on the processing. If you're trying to do lots of crazy stuff in your SQL which does things like pivoting or text processing, or whatever, and it turns out to be faster to avoid doing it in SQL and process it outside the database server instead, then yes, you were probably using SQL wrong, and the code belongs in the business layer or on the client.
In contrast, SQL excels at set operations, and that's what it should primarily be used for. I've seen an awful lot of applications slowed down because business logic or display code was grabbing a million rows of resultset from the database, bringing them back one at a time, and then throwing 990,000 of them away by doing what's effectively a set operation (JOIN, whatever) outside the database, instead of selecting the 10,000 interesting results using a query on the server and then processing the results of that.
So. It depends on what you mean by "large SQL queries". I feel from the way you're asking the question that what you mean is "overly-complex, non-set-based translations of business/presentation logic into SQL queries that should never have been written in the first place."

in many data-in/data-out cases, no.
in some cases, yes.
If all you need to work with is a simple navigation hierarchy (mainly focusing on parent, sibling, child, etc), then LINQ and it's friends are excellent choices - they reduce the pain (and effort and risk) from the majority of queries. But there are a number of scenarios where it doesn't work so well:
large-scale set-based operations: I can do a wide-ranging query in TSQL without the need to drag that data over the network in one large query, and then (even worse) update each record individually (since in many cases the ORM tools will choose individual UPDATE/INSERT/DELETE operations etc). Not only is this slow, it increases the chances of data drift. So to counter that you might add a transaction - but a long-lived transaction (while you suck a glut of data over the network) is bad
simply: there are a lot of queries where hand-tuning it achieves things that the ORMs simply can't; I had a scenario recently where a relatively basic LINQ query was performing badly. I hand tuned it (using some ROW_NUMBER() etc) and the IO stats went down to only 5% of what they were with the generated query.
there are some queries that are exceptionally difficult to express in some query syntax options, and even if you do - would lead to bad queries. Yet which can be expressed very elegantly in TSQL: example: Linq to Sql: select query with a custom order by

This is a subjective question.
IMO, SQL (or whatever query language you use to access the db) should be as complicated as necessary to solve performance problems.
There are two competing interests:
Performance: This means, load the least amount of data you need in the smallest number of queries.
Maintainability: Load as much as possible (lets say, as it makes sense) with the simplest, most reusable kind of query and do everything else in memory.
So you always need to find your way between performance and maintainability. This is actually nothing special - that's what you do when programming all the time.
Newer ways of doing db queries don't change a lot in this situation. Even if you use NHibernate's HQL, you consider performance and maintainability. You already went a step to maintainability, but you may fall back to SQL to tune some queries.

For me, the deciding factor between writing a giant sql query or a bunch of simple queries and then do everything in the code is usually performance. The latter is preferred but if it goes way too slow, I'll do the former (Sql is optimized for data processing after all).
The reason because I prefer the latter is, that in general my team is more comfortable with code then sql queries. I like sql a lot but if a giant sql query means that I'm only one who can debug/understand it in a reasonable amount of time, that's not a good thing. Another reason is also that with a giant query, you will usually program some business logic in it. If I have a business layer, I prefer too have as much of my business logic there as possible.
Off course, you could decide to stuff all your business logic in stored procedures. Your program is then nothing more then a GUI interface to the API of your database. It depends on the requirements of your project and if your team can handle this.
That said, you give Linq as an alternative technology. I have noticed in my team that thanks to my experience with SQL, I'm very comfortable with Linq while my colleagues are not. The problem on a deeper level is procedural vs set based thinking. Linq is comparable to sql. If you are not comfortable with SQL, chances are you won't be with Linq.

How about performance of linq to sql, Entity Framework and NHibernate?

I was learning this ORM because think this is good technology for most projects. But most employers required acquirement of ADO.NET and SQL.
This ORM not will use in high-loaded system (like popular web-sites)? In which types of projects this ORM will be useful? Are highly loaded projects using ORM?

If you want the best possible performance, don't use an ORM. That said, not all parts of an application need the best possible performance and good ORMs (custom built or off the shelf) significantly increase development speed.
I'm not a big fan of the ORMBattle website, but searching for questions including that term on StackOverflow will give you additional information to read about .NET ORM performance:
http://www.google.com/search?q=site:stackoverflow.com+ormbattle
For instance:
Testing custom ORM solution performance overhead - how to?
ORM (esp. NHibernate) performance for complex queries
Good ORMs result in very little overhead (on top of ADO.NET) and the performance will be just fine in the large majority of cases.
A good ORM will allow you to easily "drop to the metal" (i.e. get closer to raw SQL performance) when you need extra performance.

ORMs can certainly be performance killers. I've measured performance of Entity Framework (v1) and LINQ to SQL against ADO.NET (both datasets and datareaders). EF performance was simply unacceptable, especially in web apps where data contexts would be created and discarded very frequently. LINQ to SQL wasn't too bad, but wouldn't qualify for a high-performance application. The difference between the two is that EF is a two-layer model, without generated code to optimze the mapping between layers. LINQ to SQL is a single layer, and doesn't offer nearly as much customization; the trade-off is that LINQ queries map more closely to the relational model, so there is much less overhead.
The concept of an ORM is certainly valuable; it results in much cleaner code at the application level. But there's no such thing as a free lunch. I'm currently writing a custom ORM that maps a single data model onto both SQL Server and Oracle, with the ability to switch between servers with a simple app config setting. However, there's no LINQ IQueryable provider, and all queries are written or generated as dynamic SQL and run as ADO.NET queries. All database interaction is interfaced to the application as method calls for specific operations, and IEnumerables of entity classes returned as results. Performance is within 10% of straight ADO.NET coding, but that level of performance was a requirement from the start of the project.
While the core components of this ORM could be used in any project, the only way to get ORM and high performance is to avoid any on-the-fly mapping, either between layers (as EF does) or translating LINQ into SQL. (It's very painful to write that, because I dearly love LINQ, but the mapping cost is too much. I did make sure that LINQ to Objects works both within the ORM and in application usage with the results.)

All depends on you requirements and your architecture.
ORMs are evils when you have an reporting system and a very good for simple logic. If will implement a Repository Pattern may be will achieved a good performance.
But, as I said all depends on your requirements and architecture.
Have a look at CQRS (Command-Query Responsibility Segregation) here, this is an interesting approach of system design.

Have a look at Foundations of Programming, this is where i started.
I like to use an ORM where I have a Relational Db with a domain model (objects to be persisted). I find it to save time on development and provide cleaner code.
regarding your post about jobs, I noticed this too. However I can only speculate the answer is they still have so many .Net developers who are still learning this (ORM) there for the frameworks are not in their production systems.
I have noticed a number of Consultancy companies which seem to be using ORMS (if you are one of these companies and you do not use an orm, please correct this, I based it on your technical blogs)
IMeta (Offers Commercial support for NHibernate) UK
Engine Room Apps (they offer lessons and write apps using Nhibernate) UK
EMC2 (they did the whocanhelpme on codeplex)
HTH
bones

questions about ORM mappers like nhibernate etc

Few questions on ORM mappers like nhibernate (for .net/c# environment).
When queries are run against a sqlserver database, does it use parameter sizes internally?
paramaters.Add("#column1", SqlDataType.Int, 4)
Do they all use reflection at runtime? i.e. hand coding is always a tad faster?
does it support temp tables, table variables?

ORM World is powerfull and full featured one, I think today obstacles are peoples theirself, this to say that using ORM's needs to take changes in mind, in the way of thinkng applications, architectures and patterns.
To answer you questions:
Query execution depends on more factors, it's possible to fully customize the engine/environment to take advantages of various features like, deffered execution, future queries (queries executed in a future moment), multiple queries, and last but not least, session management involves in this area:
Deferred execution is based on concepts like lazy-loading and lazy execution, this means that queries are executed against the database just qhen you perform some actions, like accessing to methods of the NHibernate Session like ToList(), another example of deferred execution is with using of LinqToNhibernate, where just when you access to certain objects, queries are executed
Future queries are as I said beforre queries executed in a future moment, Ayende speaks well about that
Multiple queries are queries that can be "packed" together and executed in one time avoiding multiple roundtrips to the DB, and this could be a very cool feature
Session Management, this is another chapter to mention... but take in mind that if you manage well your session, or better, let NHibernate engine to manage well the session, sometime it's not needed to go to the DN to obtain data
in all the cases, tools like NHibernate generates queries for you, and parametrized queries are managed well with parameters even depending on the underlying DB engine and conseguently DB Dialect you choose!
It's clear that frameworks like NHibernate, most of the time, use reflection at runtime, but it's needed to mention the multiple Reflection optimization are used, see for example Dynamic Proxies... It's clear that somethime, or maybe all the time direct code could be faster, but just in the unit, in the big picture this could involve in more mistakes and bottlenecks
Talking about NHibernate, or better saying, It's usefull to understand what you mean when talk about Temp Tables and temp data.. In terms as are, NHibernate, as I know, doesn't support natively Temp Tables, in the sense of Runtime tables, but this could be done because NHibernate permit to create object mapping at runtime, so a mechanism of Temp data could be implemented using that api
I hope I provided an usefull answer!
...and oops, sorry for my bad english!

nhiberate uses an optimised form of reflection that creates proxy objects on startup that perform better than plain reflection, as it only incurs a one time cost. You have the option of disabling this feature as well which has nhibernate behave in a more typical manner, with the permanent use of reflection.
This feature is set with the following key:
<add key="hibernate.use_reflection_optimizer" value="true" />
Nhibernate can be used with variable table names. See this SO thread for a good solution.

NHibernate and SubSonic, LinqToSql, EF and I think most of the other ones use parameterized sql.
Most ORM's use some sort of reflection, there are some that generate all the code and SQL Query for you at design time so they don't have to use reflection code it might work a bit faster but it makes you domain a real mess and you have to use their application to regenerate all your code.
I am almost sure that they all don't support that but most have a way that you can use SP's and Views to do this.
You can check this out NHibernate Screencast Series http://www.summerofnhibernate.com/