I was wondering whether there are situation that's more advisable to use ESQL?
Generally, I find ESQL frustrating (specially with all the special cases where you need to fully qualify an entity type) & probably anything done using ESQL can be done through SQL or LINQ.
But I was wondering of situations where ESQL is a better fit for a solution or would have a competitive edge over using SQL or LINQ (either easier/faster to code, or better performance, etc.)
So, what's the compromise here? When is it better to use each one of the three approaches in querying over EF4?
I find that ESQL to be good for edge cases, for example:
Where it's just really hard to express something in LINQ.
For building very dynamic searches.
If you want to use a database specific function that is exposed by the provider you are using.
Also, if you know Entity SQL, you will be able to express QueryViews and Model-Defined Queries.
I came across these pretty similar questions (which didn't show up when I typed mine, earlier) on stack over flow, I guess they have deeper discussions (though T-SQL is not mentioned a lot, but it's kinda pretty obvious though):
Linq to Entities vs ESQL - Stack
Overflow
Entity framework entity sql vs linq
to entities
Note that the two questions are a bit "old" so you might validate some of data based on your current understanding of EF4
Just as what julie mentioned. Esql is required to write model defined functions which in return can be used through LINQ to Entities Queries.
Most cased you'll be using LINQ to Entities. One another case where you can't use LINQ TO Entities us when you want to build queries with store functions, either buit in or UDF. In this case esql is your only way in EF1 but in EF4 you can use its features to expose those functions to be used in LINQ.
About performance, esql is performing better. but you might prefer productivity using Linq over performance gain using esql.
Related
I'm currently trying to figure out how powerful ORMs are. I've written pretty simple web applications where you just needed simple CRUD queries and was super happy with the ORM I was using. But for complex analytical queries I didn't even attempt to use the ORM. It might very well be that in the specific cases it was just my limited knowledge. But on a more general note, are there any statements about any ORM that they can / cannot represent any possible SQL query? How powerful are ORMs?
(I'm most familiar with SQLAlchemy of Python)
Please note:
Yes, many ORMs support sending raw SQL. I don't consider that part of the ORM, though. My question is specifically about the ORM part only.
It's subtle. The point of an ORM is to map object to relational constructs. The ORMs I've used (mostly based on the ActiveRecord pattern) do a really good job of mapping basic SQL constructs into the object-oriented development language, and allowing you to reason at the level of an object instance in your app, rather than rows, columns and joins. As you note, this really accelerates CRUD development tasks.
In theory, I think it is possible to represent every SQL Query to an ORM construct (assuming the ORM supports all the SQL constructs in the underlying database engine).
But you probably don't want to. If your application manages orders, having CRUD functionality from the ORM is really useful. But to write the report showing order values by sales person by month in a tabular layout would involve lots of ORM complexity, but could be represented in a fairly simple SQL Query. While the ORM may support every language construct from the underlying database engine, it probably doesn't make any promises about performance.
This might be a very vague question but I guess I don't really understand what is going on. I asked a question earlier where I was told a simple way to "bind data to objects" is to just run a SqlConnection(connectionString). The response also included a comment saying I could get fancy with L2S and Entity Frameworks, so I looked deeper into those. It seems all you have to do with the DataContext object is point to the database. Why would SqlConnection be a benefit?
What is the difference (or pros/cons) of using either one of these? Is one more "standard"? Is one more modern?
P.S. I asked a lot of questions that don't all need to be answered. I just wanted to add some clarity to my question and how much I don't really understand this topic.
SqlConnection is part of the base, raw ADO.NET class library - the SQL Server part of that library, really. This is the foundation of all data access in .NET.
With raw ADO.NET, you're pretty "bare-bones" and close to the metal - you have to create your SQL queries and execute them, you get back rows and columns, very much like a relational database will give you.
Pros: really close to the SQL, really powerful, best performance
Cons: harder to write, more "glue" code, less type safety, tighter coupling to the underlying database structure
DataContext (Linq-to-SQL) or ObjectContext (Entity Framework) are higher level abstractions - they sit on top of ADO.NET, but they (Linq-to-SQL or Entity Framework) offer so called ORM capabilities - here, you're not really dealing with raw SQL statements and rows/columns, instead, those code generators will create an abstraction layer for you - which is built up from .NET objects. Each table in the database will be turned into a corresponding .NET class, with properties for all the columns in that table.
Also, with L2S and EF, you're typically using LINQ to query - your queries are much more C# like code, and L2s / EF will handle translating those queries you express in C# into actual SQL statements that SQL Server will execute.
Pros: much easier to work with, much nicer to handle (objects with properties vs. raw rows/columns), type safety, ability to query with LINQ, higher dev productivity
Cons: another layer means more translations, a hit on performance, not well suited for certain things (like bulk operations)
I need to perform queries that can be very complex, and I wanna make sure linq/queryOver can handle it.
what's the limitations and abilities I can't get with linq and can get with sql/hql ?
There isn't a list of limitations, other than the list of open bugs in Jira.
if you are performing complex queries, HQL is usually the best way to go.
However complex the query is you cna ultimately convert it toa QueryOver it might just get a little difficult and hard to read, but then you have a very strongly typed API.
Having said that you can always use HQL on your object model to achieve the same.
Session.CreateQuery("").List<>();
if that is difficult then there is always SQL to do the same.
Session.CreateSqlQuery("").ExecuteUpdate<>();
Session.CreateSqlQuery("").List<>();
My gut tells me that advanced NHibernate users would be against it and I have been looking for actual analysis on this and have found nothing, I'd like for the answer to address these questions:
What are the pros/cons of using it?
Are there any performance implications, both good or bad (e.g. use it to call stored procedures?)
In which scenarios should we use/avoid it?
Who should use/avoid it?
basically, what are the reasons to use/avoid it and why?
CreateSQLQuery exists for a reason, which is executing queries that are either:
Not supported
Hard to write
using any of the other methods.
Of course it's usually the last choice, because:
It's not object oriented (i.e. you're back to thinking of tables and columns instead of entities, properties and relationships)
It ties you to the physical model
It ties you to a specific RDBMS
It usually forces you to do more work in order to retrieve entities
It doesn't automatically support features like paging
But if you think it's needed for a particular query, go ahead. Make sure to learn all the other methods first (HQL, Linq, QueryOver, Criteria and Get) to avoid doing unnecessary work.
One of the main reasons to avoid SQL and use HQL is to avoid making the code base dependent on the RDBMS type (e.g. MySQL, Oracle). Another reason is that you have to make your code dependent on the table and column names rather than the entity names and properties.
If you are comparing raw SQL to using the NHibernate LINQ provider there are other compelling reasons to go for LINQ queries (when it works), such as type safety and being able to use VS reference search to determine in what queries a certain table or column is referenced.
My opinion is that CreateSQLQuery() is a "last way out" option. It is there because there are things you cannot do with the other NHibernate APIs but it should be avoided since it more or less goes against the whole idea of using NHibernate in the first place.
what's the purpose of entity sql, i mean if you have linq to entities why would you need to write queries in string, are there any performance reasons or something ?
LINQ to Entities does not allow you access to every feature of your database. Being able to "reach into" the database is sometimes necessary for advanced queries, either to pull them off in the first place or to improve the sometimes horrible choices that the LINQ to Entities system will make about your query.
That said, I believe that LINQ to Entities should be the first tool reached for. If the performance becomes a problem, or you have something more complex I would then encapsulate that problem piece in a stored procedure and call that. There is no reason for strings being used as the basis of queries these days.
ESQL does allow you to choose a collation on a where clause, something which isn't supported in LINQ-to-Anything. This can be genuinely useful. ESQL also allows you to specify the precise type you want returned when types inherit from each other (as opposed to LINQ's OfType, which returns instances of a certain type and any subtype). Beyond that, I can't think of a great reason to use it. It's occasionally nice to be able to build queries in strings, but DynamicQuery/Dynamic LINQ is generally good enough in the very rare cases where this is necessary.
I think (perhaps cynically) that the "real" purpose of ESQL is "it predates LINQ."
Regarding Godeke's point of fixing non-optimal queries, I have yet to see one I couldn't fix by changing the LINQ expression. Both ESQL and L2E end up as CCTs, so the SQL generation pipeline is the same.