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.
Related
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.
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 need to diagram an oracle database and I am hoping to find some good tools that are either cheap, or free.
Ideally the tool should allow me to draw the relationships between the tables, as well as remove unwanted tables from the diagram.
I already have access to MS Visual Studio 2008 as well as SSMS 2008, but I don't believe either will provide much help with oracle.
I asked this question here on serverfault, and I had several answers. However after I tried most of the tools I ran into problems with all of them.
I prefer SQL server over oracle, but I have one legacy oracle system to manage, and I am finding myself climbing an uphill battle against the numerous errors oracle throws at you on a minute by minute basis.
Have a look at TOADSoft and especially Toad Data Modeler (Toad is a very famous tool).
Another well known commercial tool is PL/SQL Developer. This is a more integrated solution (not only graphical modeling).
In both case, I didn't check the pricing but I'm sure they are worth it (and the prices must be insignificant in comparison to Oracle's license).
Like your friends over on serverfault, I had a really good experience with PowerArchitect. And it's free. . . .
Maybe I don't understand, but its only a diagram. In which any UML tool will do the job, even Visio, which should have for free or next to nothing for you, not to mention the tools in that blog. And there always pencil and paper.
Visio professional will let you reverse engineer the database schema and I've done this with Oracle before. It's actually quite good for this as you can organise the diagram into subject areas (i.e. separate pages). You can also annotate the diagrams with missing foreign keys; this is quite a useful feature for making sense of vendors' databases.
'Enterprise Architect' versions will also allow you do generate DDL from the diagrams, and you can often get VSEA2002 or VSEA2003 quite cheaply; these versions come with the EA version of Visio bundled.
I think Visio has a feature called "Reverse Engineering", with which you can specify a database connection and it will automagically draw the Diagram for you. The database connection can be anything accessible via ODBC.
(MySQL also offers such a feature in its MySQL Workbench, though I don't remember, if it was possible to specify a different database system than MySQL itself)
As long as we're mentioning pencil and paper, I'll throw in the next step up from pencil and paper. It's MS Access.
If you have MS Access on your PC, and if you can set up table links from MS access to Oracle, you can use MS Access to generate relationship diagrams, which you can then print.
You have to do a fair amount of manual work, compared to some of the pricier tools.
Set up an empty MS Access database. Then set up a table link to each of the tables in your Oracle database. Then use the Access relationship tool to draw relationship lines between each foreign key and the key it references. Classify each relationship as many to one. This creates the lines between the boxes. You can use the Access interface to drag the boxes around on the diagram until you like the visual layout. You can print the resulting diagram.
Oh, and by the way, you can create local tables to act as snapshots of some of the data, and MS queries to reload the local tables from the Oracle data. That way you can mess around with the local copies without writing to the Oracle database. You can even set up table links to a SQL server database, and move data across, bit by bit.
Depending on the complexity of your Oracle DB, and your diagramming needs, this could be enough of a tool for you.
Oracle's own SQL Developer Data Modeler has a "Free to download, free to learn, unlimited evaluation", whatever that means.
I was wondering if there are any good refactoring tools for Oracle databases and especially for PL/SQL. I'm working on a project where half the developers are working with c# and the other half on the db where there is a large and complex schema and a large code base in pl/sql. We also use sql server but the database team work exclusively with Oracle.
This code base is being worked on actively and is being refactored gradually but I was quite surprised to see how bad the refactoring tools for oracle seem to be (or at least in comparison to Eclipse and Resharper).
The developers are using Toad which only has basic refactoring support (probably as its seems to be targeted more towards db admin then development). I've used Toad myself before but always had assumed for pl/sql there were more features for working with code but had never looked into it. Now as far as I can see the only refactorings that it provides are extract method (procedure) and variable renaming. I read an article comparing sql developer and pl/sql developer and these do not appear to have any better support for refactoring. I had a quick look at the eclipse data tools project but couldn't see that they've added refactoring support since I last used it (a few years ago).
For Sql Server there exists Sql Refactor which when table structures are changed gets propagated through to the stored procedures. This for me is much cleaner and less error prone than having someone manually update all stored procedures. I used an older version of these tools on a project in the past and they seemed to be quite ok but a bit slow but that was a few years ago and it was still usable.
Something similar for Oracle would already be a big help for our developement team so I'd appreciate some pointers to good refactoring tools for Oracle if they do exist.
Thanks,
Crocked
As it happens the "D" in TOAD stands Developer not DBA. In fact many DBAs anathematise TOAD and other such tools.
You are out of luck. As far as I know there are no tools for refactoring PL/SQL. The root problem is that refactoring as a concept comes from the OOP paradigm, and PL/SQL is not object oriented. It does not support inheritance or polymorphism (*). This means that many of the techniques which underpin classical refactoring practice (say as defined by Fowler) - abstraction, interfaces, etc - have no analogue in PL/SQL.
The corollary of this is that people who are used to having refactoring as part of their conceptual toolbox tend to avoid programming with PL/SQL. I once got into a heated debate on the TDD list over this. The upshot being that even developers who need and appreciated the virtues of PL/SQL would rather develop in languages with better tool support, clause #1 of the Agile Manifesto notwithstanding.
The most important tool for refactoring is automated unit testing. Although TOAD does not (I think) have integrated unit testing, the next release of Oracle SQL Developer will. There are also standalone unit test tools. I recently mentioned a couple of them in another SO thread.
In terms of refactoring PL/SQL to match changes in the database, arguably most interaction with tables ought to be underaqtken by generated table APIs rather than being embedded in transactional PL/SQL. In this happy realm there is no need for refactoring tools, we just need to re-generate the relevant APIs. The post I linked to above also mentions QCGU, a tool which can do this. Of course, when we have a PL/SQL codebase which isn't organised in such a fashion then life is harder. You won't be surprised to learn that there isn't a lot of tool support for implementing Feathers's WELC in PL/SQL.
(*) Yes, I know Oracle has Types but they are (a) SQL not PL/SQL and (b) how many people out there are actually building APIs using them?