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.
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
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.
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.
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's DevForce may offer a more comprehensive solution.
Related
I am working on a new project for contract. Usually I go with c# asp.net and razor. The problem is, my portfolio says. C# C# C# C# over and over. I figure portfolio wise it may be helpful to have a little more variety. The other side is, a functional language seems to be an interesting approach since asp.net MVC3 is very function oriented as far as the controllers are concerned. So, has anyone tried using F# for this and did it turn out to be helpful or just get in the way?
I ask, because the controllers seem to benefit from being functional, while the models seem to benefit from an object oriented language.
I wrote some examples of using MVC3 with a mix of F# and C# and it works quite well and I also created a template that can be used as a starting point (which should appear on Visual Studio Gallery soon):
F# Empty Web Application
There are some nice things about using F# in the implementation of model/controllers:
F# types such as records make it very easy to implement the domain model
You can also use F# asynchronous workflows to implement async controllers (see this snippet)
A slightly annoying thing is that the support for LINQ in the current version of F# is a bit limited (writing complicated queries with lots of joins and grouping isn't easy). However, you can nicely use dynamic operator if you're calling stored procedures (see for example this blog post).
(I also wrote some articles about this that are not published yet - I can send you a draft if you drop me an email at tomas#tomasp.net)
Back in late 2008 there was a lot of debate about the future of LINQ to SQL. Many suggested that Microsoft's investments in the Entity Framework in .NET 4.0 were a sign that LINQ to SQL had no future. I figured I'd wait before making my own decision since folks were not in agreement.
Fast-forward 18 months and I've got vendors providing solutions that rely on LINQ to SQL and I have personally given it a try and really enjoyed working with it. I figured it was here to stay.
But I'm reading a new book (C# 4.0 How-To by Ben Watson) and in chapter 21 (LINQ), he suggests that it "has been more or less deprecated by Microsoft" and suggests using LINQ to Entity Framework.
My question to you is whether or not LINQ to SQL is officially deprecated and/or if authoritative entities (Microsoft, Scott Gu, etc.) officially suggest using LINQ to Entities instead of LINQ to SQL.
For all the "Linq-to-SQL is dead" folks: Scott Guthrie himself clearly mentioned at TechEd Europe that Linq-to-SQL is FULLY SUPPORTED in .NET 4, and Damien Guard posted a blog post on what changes and improvements have been made for Linq-to-SQL in .NET 4.
To quote Mark Twain: "Reports of my death have been greatly exaggerated"......
Last I checked, this very site uses (or used to use) Linq To SQL. Joel Spolsky mentions this in his GoogleTechTalk: http://www.youtube.com/watch?v=NWHfY_lvKIQ.
When speaking of software, "dead" is a figurative modifier (software doesn't die in any literal, biological sense), so this debate can linger on as long as the involved parties refuse to define in any literal sense what it means for "Linq To Die". Or, LTD for short. Hence, as of this moment, the LTD debate has lingered for two years. All because of a little linguistic ambiguity.
Those who say that "L2S is dead" are generally referring to the fact that L2S isn't going to receive too many (if any) new features. Updates to Linq (like the updates mentioned in Damien Guard's post) are likely to be confined to performance, usability, and stability updates. Of course, some developers might actually argue that this is a good thing (probably the same developers who are a wee bit angry about the new dynamic type).
Those who say that "L2S is not dead" are generally referring to the fact that L2S isn't going to be cut altogether from .Net (at least not anytime soon). Think: ADO. It may lose some of its traction amongst practicing developers (and that may be the unspoken desire of those crafty folks at Microsoft), but that doesn't mean that you won't be able to use L2S if you want to. It just means that Microsoft isn't trying to tantalize the masses with it.
When starting a project, I actually think it's great that I have a choice between EF and L2S. As Bill Wagner points out, there's a time and a place for both.
I am late to this discussion, but I wanted to point out that as far back as 2008, the Link to SQL Project Manager (Tim Mallalieu) made this announcement in his blog post,
"As of .NET 4.0, LINQ to Entities [rather than LINQ to SQL] will be the recommended data access solution for LINQ to relational scenarios."
I have found no other more recent announcements to the contrary.
No it is not. The team are still working on improving it.
LINQ to SQL tools in Visual Studio
LINQ to SQL was the first object-relational mapping technology
released by Microsoft. It works well in basic scenarios and continues
to be supported in Visual Studio, but it's no longer under active
development. Use LINQ to SQL when maintaining a legacy application
that's already using it, or in simple applications that use SQL Server
and do not require multi-table mapping. In general, new applications
should use the Entity Framework when an object-relational mapper layer
is required.
Make sure to have a look at this article posted on InfoQ.com - it's a really interesting one. Its conclusion: "[O]ver the long run LINQ to SQL and LINQ to Entities will merge. In the mean time, development work on LINQ to SQL will not end entirely."
i guess it's inevitsble that they'll merge. EF is really an enterprise level implementation of LINQ over db objects. linq2sql was to all intents a proof of concept(and a lot more) that actually grew legs but fuelled many of the ideas that we now see in EF. at the end of the day, the DAL layer (nhibernate, EF, l2s, subsonic etc) should be pretty far down the chain so as to negate any differences in the client BO code that implents the LINQ service - hot swappable would be the end game via DI.
I am developing a application with asp.net 4.0. My site will be a heavy like more then hundreds of user will be online at a time and lots of content will be there. I have checked both ado.net entity framework 4.0 and Linq-To-SQL with Microsoft.NET Framework 4.0 both are having great improvement over there. I am confused that which one i should use. Performance is one key aspect of my application I don't want to degrade performance of my application via making a bad choice. Could any one will help me on this? Any link or any suggestion will be appreciated.
Thanks in advance for any tip.
Google is your friend. I'm sure that you can find a lot of those threads.
Only you can tell which technology you want to invest in, but it's worth noting that Microsoft is investing the VAST majority of its effort in Entity Framework. Linq to SQL is being maintained, but is not getting anywhere near as much attention.
EF4 is a huge leap forward compared to prior versions of EF. The introduction of "Code First" is, in my view, a significant reason to adopt EF over Linq to SQL.
I'd recommend to chose the one that you can play better with, from maintenance perspective. In many cases we have based our decision on the factor of the team capability. If most of our team members have enough experience and exposure in X technology or tool, we'll prefer that over another. This way you can maintain your software without stress and also deliver reliable solutions to your customer in less time.
Question: Until now, I didn't know LINQ was an ORM tool. I always saw it as some new kind of SQL query language. So I very recently started using nHibernate.
So my question:
What would be the advantages and disadvantages of LINQ in comparison to nHibernate?
As far as I found out, the differences are that LINQ requires .NET > 2.0 (unless you hack it, which is unsafe and illegal), while nHibernate works with >=2.0.
And that for LINQ, you need to have a vendor/3rd party LINQ provider dll if you don't use MS-SQL.
What I don't know in particular is which one is faster/easier, and whether there are LINQ providers for all databases supported by nHibernate, and how well LINQ works with mono.
Linq isn't an ORM tool. Linq2Sql and the Entity framework are Microsoft ORM tools using Linq. I found this article comparing NHibernate to Entity Framework 4,0 quite enlightening.
To summarise: NHibernate, is long established and tested and Fluent is a joy to use. Unfortunately NHibernate suffers in the documentation dept, but is OS so you can dig into the code.
EF 1.0 was horrendous, but 4.0 is much better. It's a MS product so is heavily evangelised, supported and there are many examples out on the web. 4.0 is still beta for now.
LINQ is not an ORM. LINQ is just a query technology/library with special syntax in C# and LINQ and NHibernate are complementary technologies. There is even LINQ2NHiernate.
LINQ2SQL is an ORM.
With respect to speed, I would not worry too much about it unless you are making stock exchange software or something like that, where milliseconds are absolutely crucial. I believe even StackOverflow runs on LINQ2SQL, or did at some point, but I might be wrong.
There are 2 linq providers for NHibernate. They support all the database NHibernate supports
Remember that LinqToSql is really LinqToMsSqlServer - you're locked in if you take that route...
I started learning .net about 3 years ago. I have gone thru a boot camp during that time learning OO and various data access technologies such as NHibernate, Subsonic, LINQ TO SQL.
didn't wanna try EF cause it hasn't reached version 3 :)
As far as reporting goes, I have heard that many ORM'S fall flat on their face when it comes to reporting. We have AS400 OR DB2 as our backend. I have heard that LLBLGEN does a good job on reporting for this product. But it is a commercial product and not FREE. Can someone point me to some good resources for Reporting from DB2? thanks for any links/blog articles
Reporting on DB2 will work the same as reporting on almost any other database - you can use ODBC, JDBC or native DB2 calls to the database. So, you don't need DB2 reporting references - any database reporting references should meet your needs.
The only thing special about DB2 might be a little of the syntax extensions, and how you scale up the back end through parallel database servers (like MapReduce, Teradata, etc). But neither should be of much concern - since it's extremely ansi compliant and the scalability should be largely invisible to the reporting developer.
And Crystal Reports, Brio, Cognos, Business Objects, Microstrategy, Actuate, JasperReports, Birt, etc should all work fine.
ORMs are typically terrible for reporting - since they're object rather than set oriented. You'll especially feel the pain with very large data volumes, complex reports or a large number of reports.
Please, don't overlook the most obvious answer: Query/400!
It is native iSeries software. You configure and runs the report on the iSeries but it works great. It is simple, straight forward and maybe a little bit limited but you get most of the works done.
Don't be scared of the green screen or the simple interface. It's really a powerfull tool that does handle the iSeries database very well.
Can someone point me to some good resources for Reporting from DB2?
RPG I!
Light up those indicators!
Query Manager:
You cam use SQL (that can take input parameters) to build it, then create a "form" that will provide totals, level breaks, counts, customized headers, titles, etc.
Query/400 does not accept parameters AFAIK.
Free manual at:
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzatc/sc415212.pdf