views:

118

answers:

4

Building an application with a database that has the ability to get big not HUGE but definate big tables with a million records +. I just saw somewhere that LINQ isn't good for Big Datbases.

Front end will be in Silverlight and I was really looking forward to using its Skip and Take functionality for the Asynchronous calls to speed up the Clients first access to my GUI.

What can you tell me would be wrong with this scenario?

Woudl you use LINQ or something else?

MY BAck End is SQL Server 2005 or better.

+4  A: 

I would use WCF Data Services (to serve the data from the server to the Silverlight application) with Entity Framework 4 backing those services.

You might also want to check out this article from the MSDN magazine that walks you through creating a simple Entity Data Model (from the ground up), WCF Data Services on top of your model, and then how to consume those services from Silverlight:

Visual Studio - Entity Framework 4.0 and WCF Data Services 4.0 in Visual Studio 2010

Justin Niessner
I have heard Entity framework has too much overhead as far as optimizing sql it has real problems. whats the benefit? Can you offer more guidance in the statement Why. Whats Entity have thats great and makes it faster and easier? We are looking at sometimes returning 100k records to the front end.
Rico
Entity Framework matured a good bit in 4. With your data exposed as OData Services (via WCF Data Services), querying your underlying data from Silverlight is a snap.
Justin Niessner
do you have a good Link to A EF tutorial or primer. I know nothing about it. So any thoughts i have are someone elses. Educate me my man
Rico
@Rico - I just added another link with a walkthrough for setting everything up. You should also poke around the WCF Data Services site for more thorough examples.
Justin Niessner
WCF is already the form of data transfer i have chosen. I have heard mixed thoughts on EF and i should definately educate myself. I appreciate the link.
Rico
A: 

I agree with Justin you should definitely use Entities, but you should be using LINQ on the entities in the form of cached queries to Lists.

Ideablade may offer a more expensive solution.

Gnostus
A: 

LINQ actually converts your LINQ code syntax into SQL commands (under the hood). If you have any doubts about this, you can use the SQL Profiler (also known as SQL Trace) to see the SQL commands that are generated by LINQ behind the scenes. Performance-wise, it should be similar to ADO.NET.

tgolisch
so are you saying Linq over EF? Or are you stating that there is nothing wrong with LINQ for Big DBs and huge data sends?
Rico
No. LINQ actually works really nicely with EF, but works well with LINQ-to-SQL too. That tech choice is a matter of preference.I'm just saying that many people think the performance of LINQ will be poor because it kinda looks like just another middleware product, or hibernate knock-off, but it is waaay more than that.I was skeptical till I saw a SQL trace of what was happening under the hood, and realized that LINQ translated straight-through to the DB query level. The underlying queries were tight and would yield performance equivalent to straight SQL calls.
tgolisch
+1  A: 

I agree with Justin's answer and am only submitting my own answer because no one appears to have answered the question you posed in one of your comments.
  "Whats Entity have thats great and makes it faster and easier?"

* LINQ used in conjunction with Entity Framework provides a very clean syntax that after some learning curve is easier to write.
* IMO it is easier to read from nearly the beginning.
* You get Intellisense.
* You do not have the mess of SQL embedded in C# or VB.
* You get a nice document.

Bottom line is you more get better (easier to maintain) C# code.

I should also add that these same benefits can be gained from using NHibernate and other ORM tools. Entity Framework is not your only choice.

Jim Reineri
Hey this is a really good comment well put together and shows me a lot. I appreciate you taking the time to define this for me
Rico