Hello,

I'm fairly new to both EntitySpaces and Linq.  I've been experimenting with both over the last couple and days and was curious as to when/why to use one versus the other.  Currently, since we use Oracle, we can't use Linq directly.  However, with ES I can use Linq against a Collection, which is great.  Just curious about opinions on strengths and weaknesses of each.  Thanks.

I find ES query syntax to be more intuitive and user-friendly than linq. The idea behind linq is great: that a robust syntax can be used on any data in order to build filtered collections, and that the syntax is user-friendly. Linq is much better than dealing with the nuances of every individual type of data source out there. So, the idea with linq is that the same syntax can be used regardless of data source: its another attempt at standardization.

 Here is what I discovered:

1. Linq is based on reflection and determining types at runtime;therefoe, its performance is degraded.

2. Linq does not serialize well. What this means is that Linq is rather limiting in an n-tier scenario, where the client should be able to build a query and request a result set back from a service by providing the requested query (filter) info. I have learned that the dynamic benefits of linq come at a significant cost and that linq does not work well in anything other than a 2-tier (client-database) scenario (in my opinion). Serializing an object graph requires very challenging and robust design (serializing gobject graphs does not work - 'out-of-the-box' with linq because you have to serialize the object meta data just to pass along a query request). The work-around is to pre-create the possible "parameters" in a query request and build the actual linq query on the service-side. Frankly, linq sucks compared to ES in n-tier scenarios. Can  you use it - yes. Is it better than ES - not in my opinion.

3. A disadvantage of ES is that queries are based on typed objects. Well, for me, this disadvantage is the main advantage. The result of using ES is much faster performance, query requests and objects are serializable, and you still get database independence - you donl;t have t change your code to switch databases.

Honestly, because of the object graphing problem and performance cost associated with linq, I have rejected it. NOTE: I only rejected it because I think the ES sytax is better anyway. Its easier to read/create. Its serializable. Its customizable. Its database independent. Its fast - rocket fast. It optimizes queries for performance.

So, I think many ES benefits can be gained by using ES in conjunction with linq; however, I think ES beats linq in every category. Maybe someone else has differing experience, but I am not aware of any gain using linq instead of the ES query syntax. I am aware of losses using linq instead of the ES stntax.

...just my two cents

Now that Visual Studio 2008 is shipping, we are not under any delusions about what will be the new, de facto standard. LINQ is backed by the 800 pound gorilla, Microsoft. However, I whole-heartedly agree with TrevorW's analysis. The combination of the EntitySpaces Architecture with DynamicQuery is superior on a number of fronts. With SubQuery support in ES2008, DynamicQuery will be even more competitive against LINQ.

... just my biased opinion.

and while we're at it ...

EntitySpaces runs on the Compact Framework, Medium Trust, Mono, not to mention all of our supported databases. And LINQ is pretty much useless without using the ADO.NET EF which is not where EntitySpaces is at all when it comes to performance. Like Trevor said, our Queries are more intuitive (my eyes gloss over when I look at LINQ queries) and our code can be written to be binary independent (as our unit tests are). Also, you guys have a direct impact on our releases as you can tell from our latest blog post and issues coming directly out of forum posts, and you can make a post like this and get a response from the guys that make it happen. Trevor does a good job of listing many other reasons as well.

LINQ is just a query mechanism, you still need an architecture. If you need agility, support for all kinds of databases, and the ability to take your architecture anywhere you need to go whether it be wireless, medium trust hosting, or mono, then EntitySpaces is an excellent choice.

These are the numbers from our ES2008 .NET 3.5 runtimes

EntitySpaces.Core.dll              70 KB
EntitySpaces.Interfaces.dll        53 KB
EntitySpaces.Loader.dll             6 KB
EntitySpaces.SqlClientProvider.dll 42 KB
========================================
                                  171 KB

Of course, you have your generated classes that add to it. I look at LINQ and think "So what". I like our API better, and it will continue to get more powerful and we will add even more databases. You want to try something fun? Go to http://www.mysql.com/ and search on LINQ. Not everybody will be Microsoft's cheerleaders on this.

Frans Bouma of LLBLGen has spent the last several months (3 or 4 or more) writing LINQ for LLBLGen, we're not about to take that course. LLBLGen needed a new way to query for sure as it's syntax is extremely complicated compared to EntitySpaces. We feel we are well positioned and don't feel the need to drink any funny colored liquids