I am using SQL Server 2005 in a project. I have to decide about datalayer. I would like to use LINQ in my project. I saw SubSonic 3 supporting LINQ and I also have option for LINQ to SQL, because i can have typed lists from LINQ to SQL.
I am wondering what is different between LINQ to SQL and Subsoinc 3 LINQ, Which is beneficial?
Thanks!
JAMIL
In case you haven't read this already, the Subsonic site has a pretty lengthy overview of some differences between LinqToSql and Subsonic (and NHibernate).
http://subsonicproject.com/docs/Comparisons
Outside of specific differences of the technologies, you may also want to consider the implications of going with an open-source 3rd party tool vs an official Microsoft product. There are pros and cons to each! ;)
although NHibernatebe greater ORM than Linq2SQL, NHibernate Linq is very very limited.
If the idea is to use LINQ, choose Linq2SQL, because Subsonic also have several limitations.
If you remove LINQ from equation, then NHibernate will be the best solution, but only for complex and bigger applications.
For small ones, uses Subsonic or even Linq2SQL
LinqToSql has many very significant downsides and it's almost never the right solution.
SubSonic 3 has many of the benefits of LinqToSql with few of the downsides.
If you must choose between these two, SubSonic is a very clear winner.
In the end, NHibernate is significantly better than both and for most projects it is clearly the best way to go.
That said, you can go a long way with SubSonic and it is a good product. You just need to be aware that there are limitations and places it won't go that NHibernate will go.
Related
Recently, we have updated our nHibernate to 3.2.
Now, two new options added for us to write queries - Query (LINQ) or QueryOver(iCriteria).
From what I read, QueryOver is dedicated to nHibernate and more powerfull for complicated
queries.
On the other hand, LINQ is universal and if tomorrow I change my ORM, my queries stays as
they are. Another important reason for me to use LINQ, is the fact that on LINQ I found much more documentation
and examples than on QueryOver.
Actually, I prefer to use LINQ, and I want to be sure that there is no critical reason why i shouldn't do this.
Thanks in advance,
The chances of you swapping out your ORM are very slim to none.
Both QueryOver and Query have their pros and cons.
But the benefit of NH is that you can easily flick between any of it's querying capabilities. Where I work we use a mixture of QueryOver (primarily), Query, HQL and on occasion direct SQL.
While a lot of LINQ queries from NH will easily translate to EF, LightSpeed, or your choice of ORM, there is a whole heap of NH specific LINQ such as Fetching that are built into the LINQ provider that will make it difficult to swap-out the ORM at any point.
Sometimes QueryOver queries will generate better SQL than Query, and vice versa, so just use what you prefer and profile your queries when they are executed to ensure that the generated SQL is efficient.
As for now, unfortunately both have their limitations and there's a lot of work to be done by nHibernate team to match the expressiveness of Linq2SQL where most of queries just work.
Most of the time I use Linq (Query) but it has some unexpected problems on relatively simple queries which involve grouping and some subtle bugs (like the infamous "invalid cast" on byte? https://nhibernate.jira.com/browse/NH-2812). Switching to criteria api (QueryOver) usually helps.
As for now (3.2) it is then impossible to give a straight recommendation. I would stick with Linq, temporarily switch to criteria whenever you encounter issues and when bugs and limitations are removed in future versions, you could go back and try to rewrite everything to Linq as it should serve as the primary query language.
There are a number of posts on here mentioning Linq support in NHibernate, but they are 2 years old. NHibernate 3.1.0 has a built-in Linq provider. I am wondering what kind of limitations it has, or should I charge forward in knowing that I won't run into too many problems? Will I end up having to use the native query language in NHibernate due to limitations in the Linq provider?
The 3.x LINQ provider keeps getting better. It supports lots of constructs, although not as many as EF. It's really usable.
Now, you write "Will I end up having to use the native query language in NHibernate" like it was a bad thing. It's not.
NHibernate has 5 different query methods (Criteria, HQL, LINQ, QueryOver and SQL). Each has its strengths and weaknesses, adapting better to different usage scenarios.
My suggestion is that you learn them all, and use whatever fits best what you're trying to do in each case. LINQ, regardless of the provider, is always leaky when talking to a SQL DB. Keep that in mind.
Just wanted to know if NHibernate 3 have full linq support yet ?
Thanks.
There is no such thing as "full" LINQ support.
LINQ to anything except Objects is a leaky abstraction. Some operations that are trivial to express in an object model are hard to translate to SQL, and vice-versa.
That said, the LINQ provider in NH3 is quite usable, and a lot of work is being put into it (a lot of that will be visible in the 3.0.1 release, which will be out around 28/Feb/2011)
The good news is with NH you always have alternatives. If you can't do a particular query with LINQ, there's always HQL, Criteria, QueryOver and even SQL. They all integrate nicely with the rest of the stack.
No there are still some unsupported features. It's not a full LINQ implementation.
It doesn't have full linq support because it is too much (impossible much) work to write a full link provider. I don't think any full linq provider exists.
You can find the currently unsupported features in Jira.
So, I'm starting a new Project in my company, and it's kinda big. We are going to use .NET 3.5, and I wish to known if there are any know bugs or perfomance issues that could give weird behaviour for my project? I'm reading some things about EFv4 and all they say is that EFv3.5 have too many problems.
After all, what's the best and fastest way, ADO.NET Entities or extract the data from my DB directly to a DataReader? The EF Oracle provider is stable?
The project will be .NET 3.5 and Oracle.
The first problem you'll experience out of the gate will be the Oracle/EF hurdle. Since neither Oracle or MS provide one you'll have to go third party. There are a few out there.
There are other ORM's out there.. maybe this is a good comparison?
http://ormeter.net/
I also think your question might be better served by asking "What ORM should I use given X technology". You should be picking an ORM based on your requirements and constraints.
Well if you were looking to EF you might also consider Nhibernate which in my expirience is much better. At work we tried both and chose the second because you can also write some raw Sql (hql) query in it.
If you still decide to use Ado I and the size of the project is big you'll need an amount of discipline not to mess with sql query strings around.
PS:
Forgot to mention that NHibernate supports also linq which also generates better and cleaner sql queries comparing to EF.
I was just reading about Linq to SQL being discontinued. For a while I put off learning Linq at all. Even on asp.net, when I last checked, their data access tutorials were using table adapters and bll classes. Then there are linq tutorials. Now that I have read this and that the Entity Framework is the new way to go, does that mean all the Linq "stuff" I have been reading about for a year and a half, how great it is, etc., is all this just gone? No one ever seems to settle on the right way to do things or at least some standard way with MS products. And I understand that you can't say one way is right for everything. But, in this particular case I do not understand why there cannot be some settling on data access.
Or, is Linq To SQL just the ORM portion of Linq? What exactly would I learn now if I wanted to use an ORM? I have read several things on StackOverflow, but none that really help me know what to do.
It seems that nHibernate may be better than any of the Microsoft choices. Yes, I know there are others (subsonic, and others were mentioned in various SO questions.)
Thank you.
No.
LINQ to SQL is built on top of LINQ, which is one of the fundamental added language features in .NET 3.5 Framework.
Technically other ORMs can implement their own LINQ systems, e.g., NHibernate already has LINQ to NHibernate going. This is on top of the ones provided in the framework, such as LINQ to XML, LINQ to Objects etc.
The Entity Framework certainly doesn't mean that LINQ is going away - the Entity Framework is a LINQ provider itself!
LINQ is a whole collection of technologies, and more than that - it's a pattern which you can implement for your own data provider as well.
LINQ to SQL is just one example of that pattern. For what it's worth, I think LINQ to SQL is being de-emphasized rather than actually going away, but we'll see...
Personally I find LINQ to Objects the most useful LINQ provider in the first place :)
Linq to sql is just one of many linq providers out there (there is linq to db4o, linq to starcounter, linq to objects, linq to ado and many, many more). The entity framework has its own linq provider, called linq to enteties. Your year of reading about linq is not lost.
Linq is much more than Linq-to-SQL. Things like Linq-to-Objects and Linq-to-XML are part of the technology, for example.
I doubt they are going away! Fingers crossed. ;-)
LINQ hasn't gone away. LINQ to SQL hasn't either, but it is not Microsoft's strategic platform for data access, that would be Entity Framework. EF uses LINQ to Entities so if you've spent time learning about LINQ, it'll still be valid and useful.
LINQ isn't a product-specific technology, though. It is easy to leverage the power and flexibility in collections of (almost) all kinds. eg.
List<MyType> myList = new List<MyType>();
// populate the list here
var filteredResults = from o in myList
where o.property == "hello world"
select o;
is (conceptualy) valid, even if the code example here is flawed.
LINQ is a library for processing sequences of data. And it is pretty awesome.
These sequences of data may be anything that implements IEnumerable, or it may be whatever sequences are provided by adapters.
Linq to SQL is an adapter which allows a SQL database to provide sequences of data that are compatible with LINQ.
There is also a Linq to XML which is an adapter that lets you treat an XML document as a sequence of data, allowing LINQ to process it.
LINQ is just the query language, and it is extremely good at what it does. It has nothing to do with databases or SQL. It is definitely worth learning just to be able to process in-memory collections easily.