Welcome Guest - Login
PLINQO
home Home
feature-tour Feature Tour
getting-started Getting Started
download Download
documentation Documentation
Forums Forums



Quick Search
»

PoweredBy
Get CodeSmith Free! We want to get the word out about PLINQO and are willing to give CodeSmith away in order to do so. Check out the details!
We have gone through what seems like every ORM possible and we strongly believe that PLINQO is the best ORM available, period. PLINQO provides an extremely light-weight, fast and RAD experience. PLINQO makes working with data just plain fun. When you think success, think PLINQO, my friends.

Shouldn't I be using Entity Framework?

When we looked into Entity Framework, we found it to be bloated, complex and seemingly designed for large, ugly, enterprise databases where entities don't remotely match the storage schema. (FYI: If you have one these suckers, good luck with that.)

If you require a 2nd opinion, look here, here and here. Hmm here, here and here. Oh wait, don't forget about the petition signed by 750+ people.

How exactly did Microsoft end up with two ORMs?

The Data Programmability Team never owned LINQ to SQL, it was owned by the C# team. It appears that it was slightly political that we have two O/R mappers and we think this is apparent in the design of the two frameworks. LINQ to SQL is more of an object API and much more natural to discover functionality. This is a major reason it is easier to use, learn and understand.

Did Microsoft really say LINQ to SQL was dead?

No, Microsoft has never said that LINQ to SQL is dead and improvements are being made according to Damien Guard's LINQ to SQL 4.0 feature list.

What happens if Entity Framework stops sucking?

That day is still seemingly in the distant future. The next version of Entity Framework may come close to offering a solution that will provide more advantages than LINQ to SQL. So when that day comes and Entity Framework stops sucking, we will enhance PLINQO to support Entity Framework and make it as easy as possible for those that have made the wise choice to use PLINQO. Remember, LINQ is provider based, meaning your code is written to the LINQ interface, making it straight forward to migrate.

In the meantime, since we need to build applications and make money now, the best framework for the job is LINQ to SQL.

Don't you like money?

PLINQO cuts down development time making applications easier to build, use and maintain. PLINQO is refactor-friendly allowing you to make changes, regenerate and you're good to go. The only real thing Entity Framework has going for it is that it supports databases other than SQL Server. If you use SQL Server and have no plans to switch to another database, do you really care about this "advantage"?

Is what they say true? Is PLINQO the fastest ORM in the world?

Well, fastest in the world may not be proven... yet. But, it's pretty dang fast.

Many tests have proven that LINQ to SQL is faster and generates more efficient SQL than Entity Framework. Entity Framework generates database agnostic eSQL which will then be translated to T-SQL or another database vendor's flavor automatically while LINQ to SQL skips this intermediate step and generates T-SQL. This is largely why LINQ to SQL generates more optimized queries. This performance test points out that LINQ to SQL's lightweight RAD approach is a much leaner, faster way to get your data back from SQL Server. Another set of tests comparing start up times between LINQ to SQL and Entity Framework showed that LINQ to SQL initializes and instantiates much faster than Entity Framework as well.

Now that we have established that LINQ to SQL is fast by itself. Let's talk about PLINQO's performance enhancements. Batch updates, batch queries, batch deletes, query caching, longer lasting enjoyment, multiple result sets... need I go on?. If high performing applications is something you desire (we haven't met anyone with a goal of slowing their application down), PLINQO again looks like the obvious choice.

What about NHibernate?

We looked at NHibernate as well and we thought it was a great framework, but the configuration was epic and LINQ support was vaporware at the time. We considered LINQ to be an absolute necessity and that is why we chose to not use NHibernate. Even to this day, there is only an interim LINQ implementation which is far from complete. LINQ to SQL has the best LINQ implementation out there right now and that is why we built PLINQO around it.

Powered by ScrewTurn Wiki version 3.0.1.400.