Related
So what's the verdict on these two products now? I can't seem to find anything regarding this issue SPECIFICALLY for VS2010/.net 4.0
Back in .net 3.5 days, most people believe Linq2SQL will be dead when .net 4.0 comes around, but it seems alive and well.
On the other hand, EF 4.0 seems to have gotten significant improvement.
For me, most of my work so far are small to medium sized projects, and my company is migrating from VS08 to VS10 soonish. What should I be looking at? Or really, should I spend the time studying EF4.0 or would it be time more well spent looking at nHibernate? (But back on topic, I'm really more interested in Linq2Sql - EF.)
Lastly, I am currently using entlib / unity, which framework is more friendly for dependency/policy injection?
Thanks in advance.
Here are some reasons why Entity Framework (v4) is better:
1 - L2SQL is essentially obsolete
2 - L2SQL does not support POCO mapping, EF does.
3 - EF has more flexibility (code first, model first, database first). L2SQL has only 1.
4 - EF has support for SPROC -> POCO mapping
5 - EF has Entity-SQL, allowing you to go back to classic ADO.NET when required
6 - EF supports inheritance (TPT, TPH)
7 - EF goes hand-in-hand with Repository pattern, and deferred execution via IQueryable
8 - EF components (ObjectSet, ObjectContext) are easily mockable and allow for DI
I cannot think of any reason why new projects should use L2SQL.
Some might say "Well L2SQL is good for small projects, i can drag and drop and be done with it".
Well you can do that with EF4 as well, and you'll have more flexibility/support in the long run if you decide to modify/grow your project. So that is not an excuse.
HTH
Just to add to the previous answers and comments (all three got a +1 vote from me):
a) Performance: the L2S runtime is more lightweight than EF (due to only a single layer; EF has to deal with two model layers and the mappings between them).
EF often generates a bit more verbose TSQL than L2S but most of the time that only affects readability if you're profiling and looking at the generated queries; the SQL optimizer will end up with the same execution plan most of the time. There are however some cases when the queries can grow so large and complex that it can have a performance impact.
L2S is also slightly better at doing client-side optimization of queries; it eliminates where clause predicates that can be evaluated client-side so the database don't have to worry about them. This means less work for SQL Server's optimizer, and less risk that you'll end up with a 'bad' execution plan.
b) L2S vs L2E: L2S is still slightly better than L2E at translating LINQ queries that use normal CLR methods into TSQL, especially when it comes to DateTime and methods related to it. L2E supports more or less the same things but through its' own EntityFunctions class: http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspx.
Both L2S and EF are great choices in my opinion, pick the one you feel comfortable with and covers the things you need now and during the reasonable lifespan of the code you're writing. Before you know it, Microsoft will probably announce yet another data access technology. They seem to do that every 3-5 years... :) DAO, RDO, ODBC, ADO, OLEDB, ADO.NET, typed datasets, ObjectSpaces, WinFS, L2S, EF, ... etc etc. Code I wrote 15 years ago against DAO is still out there, in apps that are still on the market, and it still works despite DAO being "dead" for years.
Sometimes names are reused for completely new data access technologies, but that doesn't change the fact that whatever constitutes Microsoft's latest database access technology is a constantly moving target...
L2S isn't going anywhere. The VS team has made that clear. It won't get significant improvement, but it will still be around and work just fine.
L2S is great, and easy to use for small scale projects with fairly simple data models. The trigger for me, when to choose EF over L2S is if I have many-to-many tables, or I need to map more complex entities over more than just a single table.
I know this is probably too late for the original query, but for the sake of future people with a similar question...
To my mind, the crucial aspect is whether you're doing an entirely new project or working with a legacy DB. I'm working with a legacy DB, with some rather idiosyncratic design decisions. I'd like to use EF, but it simply failed to map over these idiosyncracies, while L2S managed perfectly well.
For example. Some of the FKs contained other values than keys to related rows - effectively doubling as an FK/flag column.
Further, the FK inheritance mapping totally failed against out DB, so I opted for a flat L2S model, to get the benefits of type-checking and name checking at query time, but ended building my own mapping layer.
All of this is a horrible pain, if its any consolation to MS, I also found NHibernate incapable of the task. In my experience, in real-world usage too many DBs have these kind of issues, hence my recommendation that EF is not really suitable for brown-field develop ment.
For new projects, you have the luxury of evolving your DB design to match the assumptions of the framework. I can't do that as existing applications rely on the data design. We're hoping to improve the design incrementally, but attempting to correct all the problems up front would result in an infeasibly large migration event (for our resources).
Note: In the UK (at least), brown-field development is building houses on land that has previously been developed. Green-field development is building on our dwindling resources of countryside. I've reused the terms here.
We've just moved from VS 2008 to VS 2010 and from L2S to EF.
Even though we are using EF in a very similar fashion to L2S, it comforts me knowing that I have flexibility to do more advanced ORM should the need arise.
That said - for a small project - I would probably still use L2S. Medium to large projects I would use EF.
Also - EF seemed like a big learning curve, because the EF documentation prompted us to start investigating some design patterns like Unit Of Work, Repository, Dependency Injection. However I realised that these patterns applied to L2S as well as EF.
In terms of Nhibernate - my research (ie. browsing SO) indicates that the latest version of EF4.0 is sufficiently advanced (POCO support etc.) to be considered a competitive product.
If third-party products are appropriate for you, try using LinqConnect. This product allows you to use Linq to SQL (with some modifications) with different DBMS (Oracle, MySQL, PostgreSQL, etc.).
LinqConnect offers you the following features unavailable in L2S earlier:
Model-First approach
TPT and TPH support
POCO support
Automatic synchronization of model and database without data losses.
As for performance, the latest comparative test on OrmBattle our provider is among leaders.
Also, all EF functions are supported in our DBMS-specific providers as well.
Is Entity Framework worth moving to for a new small app? About 10 tables and a WinForms app.
ie the alternative being DataTables/DataRows or Linq-to-SQL
I'm going to disagree with those who say that LINQ to SQL is preferable for a small project, based on real-world experience using both LINQ to SQL and the Entity Framework for small projects. I have a really hard time getting over LINQ to SQL's incredibly weak schema update scenario (throw away your old model, re-generate a new one, and re-apply your customizations). You can do what you need to do with both tools, for the most part, but if your DB schema will ever change or evolve you'll spend way too much time fiddling with the L2S designer.
The best reason to avoid the Entity Framework is if you don't understand it. I'm not being flip here; if you do understand L2S and you don't understand the EF, then by all means use L2S; you will probably be more productive. But if you understand both tools, the EF can do nearly everything that L2S can do and much, much more (easy model updates, model-first, code-first models, customizable codegen, RIA services, etc., etc...).
Entity Framework is a great product - but it's clearly designed for more advanced, more complex cases, where you need to be able to have a domain object model that is or can be different from your underlying storage model. If you need that - great - but for most smaller apps, this is total overkill and only adds additional layers of performance killers.
For a small app, go with Linq-to-SQL - or have a look at Subsonic. Those both offer quite thin and very simple layers on top of your tables, and they work great for smaller apps.
DataTables are so 1990's .... stay away, they're messy, they're hard to use, they're not pleasant and not efficient to work with.
I would probably go for LINQ to SQL for a small project.
Stay away from datatables. LINQ to SQL should be enough, IMO.
The relative simplicity of Linq-To-Sql as well as all the criticism leveled at version 1 of Entity Framework (especially, the vote of no confidence) convinced me to go with Linq-To-Sql "for the time being". Now that EF 4.0 is out, I wonder if it's time to start migrating over to it.
Questions:
What are the pros and cons of EF 4.0 relative to Linq-To-Sql?
Is EF 4.0 finally ready for prime time?
Is now the time to switch over?
Well, an endless debate :-)
Yes, I firmly believe EF4 is definitely ready for prime time - Microsoft has done an outstanding job of addressing just about all the annoyances and issues with the 1.0 release of EF.
It's ready for prime time - if you need all its features.
Linq-to-SQL is a pretty straightforward, no-frills, no-nonsense OR mapper - it maps one database table to one CLR object - and that's about it. Very basic, very direct - but a rather thin layer on top of SQL Server.
EF4 on the other hand is much more
a conceptual data model in your object space
a storage data model on your database layer
a mapping layer between the two
database-independent
So if you really need support for multiple databases (and not just SQL Server), or if you really need to be able to morph the database structure into a totally different object model - EF4 is a great place to start.
If you have a simple and straightforward little to medium-size app that only needs to be able to easily and quickly map tables 1:1 to objects, then I don't think EF4 comes even close in terms of simplicity and performance to Linq-to-SQL.
EF4 is great - and if you need its power - go with it!
But if your requirements are a lot less, it might just be overkill - continue to use Linq-to-SQL (I will) and be happy with it. I don't see any good reason to dump Linq-to-SQL - it's still totally available in .NET 4, has been blessed with some bug fixes and improvements even, and it will be around for at least another couple of years.
#marc_s, #DanM:
Please do not consider this post as an advertisement :) We just want to know the opinion of advanced users of Linq to Sql.
We have implemented the following improvements in our LinqConnect (Linq to Sql Server, Oracle, MySql, PostgreSql, SQLite):
- Complex Type
- Many to Many
- Batch update operations
- Recursive support in DataLoad options
- Query level preload (like Include in EF)
- TPT support (in LinqConnect 2.0)
We also plan to add support for second level cache.
Are these improvements valuable for you?
We are building a RESTful API for our company, which will provide XML, JSON, and potentially other content types.
My team is looking to find a framework which is (In order of priority):
Well Documented
Ideally with good tutorials, and a thriving community and knowledgebase
Follows rational design patterns
Mostly we want consistency in the framework. Naming conventions that don't change based upon which method call you're calling.
Secure
Focused on forcing the developer to perform some form of validation of the GET, POST, PUT and DELETE Variables
Stable
Part of this is maturity, in the sense that the framework isn't changing too often
The other part is a well documented bug list which isn't scarily huge
Scalable/Performance Oriented
We have over 50K users who require significant high availability all around the world. IF our App goes down, people do not have internet in their home. So it's a highly critical environment.
Ideally we could launch the same codebase on 10 servers and just keep adding loadbalancers. We don't want to have to define which server is on which methods....
Integrates well with a Linux/MySQL Environment
We don't have a single MS server. We're not changing that. Sorry .Net fans :-D
I realize this a nebulous goal. There will not be any one framework that meets all of these needs, in fact there will probably be many that meet them in varying ways, shapes and forms.
This is language independent. We already have experience in PHP, but we also have developers who have never written a web application in their life, so learning Python or Ruby or Java is acceptable.
I'll go out on a limb here and suggest Ruby with Sinatra.
Why?
Sinatra isn't "well documented" but is "documented well". Considering that it is much more simple than other frameworks there needn't be quite so much documentation, and since it is built on Rack as a webserver it shares some common documentation with that. But what you need to know is on the website, and it's well written and contains no errors that I've found (IE, it's all up to date).
Most of what you need to know is in the Sinatra Book, the Readme, and the FAQ. Despite the work-in-progress nature of the book its contents are very much accurate and useful. And, if you are still stuck with questions, drop by the IRC chat room freenode.net#sinatra.
Sinatra is capable of being used in a functional/route-based logic method, or by overriding the Sinatra::Application object. You can use either, split your logic and methods into various files, or keep it all in one. It's all up to you.
Sinatra is, of itself, secure. You MUST validate all variables sent by the user, because aside from parsing them and passing them to you, Sinatra doesn't care how valid it is. Therefore, you either enforce validity of your variables or you regret it. ;-)
Sinatra hasn't changed a bunch in the last four months, but it certainly has had maintenance and minor updates. In addition, I've not found the bug list to be large or threatening. It's got virtually everything I need already to build my apps with.
Sinatra doesn't have to be deployed with Passenger, but can easily be custom tailored to be fast. If you use things like Enterprise Ruby and Thin you could proxy to either Nginix or LightHTTPd. If you took two servers you could make one the primary (with the proxy and a number of threads) and the second the database server (with MySQL and a number of threads) and let them loose. This way the tasks are spread across the servers. It'll give you more control than I think Passenger would. (Not to mention better performance.)
I find Passenger (on Dreamhost) to give relatively poor performance when compared against running threads by either Rack, Mongrel, or Thin. That said, once loaded the applications are responsive even in that environment. If I were to predict it, you'd not have a problem with scaling the application as you'd simply have to redeploy your code and restart the threads–nothing that can't be put into Capistrano.
Ruby on Linux is fast and isn't a problem to implement. MySQL with Ruby is easy enough, and there are several really good ORM packages available like ActiveRecord and Sequel. Sinatra won't make you choose one that you hate.
In addition to the answers to your questions, I have a few more reasons.
Sinatra has an easy learning curve, and is very easy to pick up. The biggest problem I had was getting it onto my Dreamhost server since Rack was an older version, but with a vendored version of Rack the problem vanished. If I could, I'd rewrite my latest Rails project in Sinatra with ActiveRecord so as to make maintenance easy upon myself; too much effort was spent in it already.
Thanks to its ease of use and ease of learning, I have found myself more productive in Sinatra without code generators than in Rails with all the code generators. And that's saying something.
Sinatra supports middleware for Rack, and is therefore very flexible in what you can do with it.
If I were to average out the helpfulness of the Sinatra community, on IRC, I'd say that they're more knowledgeable about the framework than the average Rails user–just as a cursory comparison. The reason being that Rails is more accessible to newbies and people who just have no business programming.
Sinatra will support Ruby 1.9. I'm still not entirely certain just how much support for 1.9 there is currently in Sinatra, but I do know they were initially waiting on Rack. As of April 25 this is no longer an issue, so presumably Sinatra is already prepared for 1.9; I know for a fact 1.9 support is in the pipeline for mid 2009, but I don't know how long that will be.
Assuming you can get Sinatra working with Ruby 1.9 with a little effort (version 0.9.2 already supports Rack 1.0, and by proxy 1.9 in Rack's code), before the public 1.0 with support for 1.9, your performance on the Ruby side would be stellar. Even if you cannot, then Enterprise Ruby would help the speed.
Both Django and Rails come pretty close to fitting most of your criteria, except I think that Django's documentation is way better than that of Ruby on Rails'; the documentation for Django is nothing short of amazing (and I'm not being hyperbolic here).
I don't know about the scalability of Django, though. I know Rails scales pretty well (up to a point), but I don't know if the same can be said of Django. (I'm not saying it can't; I'm just saying that I honestly don't know, as I've never written a large application using Django.)
Django also has a pony, in case you secretly desire that, too.
Well. Scalability is nothing easy to get. For Google-like response times, you need something like MapReduce. Ok. Don't kid yourself, super-scalability is nothing for beginners.
As for all the other points, Seaside is clearly best. As for security, check out seaside.st to see why it is inherently more secure than all the other frameworks I am aware of (including Rails and Seam, e.g.). Seaside is reasonably well-documented, but also looking at the internals of seaside is so easy and convenient, that hardly a question remains open for the community to answer, which it does fast usually. Seaside has been stable for many years now, so I think you'll be fine with that.
As for Performance oriented: Run the commercial Seaside, GLASS, and you will get stunning performance compared to a LAMP-like setup, due to the much faster database solution that is integrated, and the framework which trades memory for speed and gets a lot of speed.
Seaside is architectured so well that many people find writing Seaside apps easier than desktop applications. Try it out, you'll love it.
PS: For the record, Seaside is not RESTful.
You can have a look at Django, Python framwork.
It's a very well documented framework, it has an automatic CRUD administrator interface on database and it has also a free book online, that of course you can buy for real :)
Try them all to find out the correct answer!
Well, the people who will be suggesting 'one framework to rule them all' won't have tried them all either!
I guess if there were such a framework, it would be one and only.
For PHP, I've loved the Zend framework (though, to me it is not really a framework). One of it's best features is that each component is independent of the others... So if there is some part of it you don't like, just don't use it. Also, you mention JSON... Zend fully supports JSON in both directions....
Ruby on Rails is vastly documented with loads of plugins and has been tested in scalability already ( see BaseCamp and other solutions made in rails)
Looking at your list of priorities it's hard to say that any one route is the "right" way to go. On the PHP side I've spent a significant amount of time with CakePHP which accomplishes much of what you looking for. But being a guy who hates PHP I would suggest steering clear of anything in that realm.
It's all about style and experience. I've used Ruby On Rails, which isn't the most elegant of languages but it does the job exceptionally well. It hadn't matured as much as using a Spring/Hibernate stack on Java or using .Net which handles almost everything straight out of the box, but it does the job exceptionally well. I prefer the Java/.Net based projects because it fits much better with the way I like to program.
There is no "right" answer, just lots of good ones. ASP.Net MVC for example is a good choice. Forever ago I used Spring on Java which was also fairly effective at accomplishing the job. Even PHP is not a wrong choice. Ruby On Rails, which I have only done two projects with, is very easy to pick up and it makes some rather complicated tasks in other languages fairly simple.
I think that for sheer volume of documentation you can't beat J2EE. It's also believed to be insanely scalable and stable.
Now, from there to really being desirable....
If you're considering Java I would recommend Jersey, it works great and I think it reaches all you 5 goals...
If Java is in your toolkit, look at Stripes.
Rock stable, enthusiastic, though no a spectacularly large community. Good docs, some out of date granted, but the system is so stable even the "old stuff" is relevant. A real nice, recent (late last year) book. Stripes is small enough that the book can, and does, "cover everything".
It's an action framework, doesn't do much in the presentation area (save for forms, mostly, and it has a completely optional templating/layout facility). You can use JSP or FreeMarker, or, really, anything else. It can also do web services (though not as well as something like Jersey).
It is back end agnostic, but there is a JPA integration project for it.
Finally, you can leverage, if you like, all of the other Java/Java EE kit if you want. Since Stripes doesn't consume the entire stack, you have a lot of flexibility to pick and choose the parts you want. Full boat Java EE, Transactions, Session Beans, JMS. Works with Spring (it is "conscious" of Spring and has good integration) JPA, iBatis, Hibernate, raw JDBC, Lucene, JSR-170 Content Repository, whatever.
It's a great piece of kit.
For a 2014 answer, I would recommend Laravel/Slim Framework (PHP), Ruby on Rails/Sinatra (Ruby), Django/Flask (Python), Grails (Groovy, JVM-based language), Play! Framework (Java/Scala) or Sails.js/Kraken.js (Javascript).
Where the first framework mentioned is a bit larger and the second is a bit smaller for the languages where I mention 2 frameworks with the use of a "/".
I hope this helps people that have similar questions 5 years later.
Try cppcms
it is a high performance Web Development Framework
I'm toying with the idea of phasing in an ORM into an application I support. The app is not very structured with no unit tests. So any change will be risky. I'm obviously concerned that I've got a good enough reason to change. The idea is that there will be less boiler plate code for data access and there for greater productivity.
Do this ring true with your experiences?
Is it possible or even a good idea to phase it in?
What are the downsides of an ORM?
I would strongly recommend getting a copy of Michael Feather's book Working Effectively With Legacy Code (by "Legacy Code" Feathers means any system that isn't adequately covered by unit tests). It is full of good ideas which should help you with your refactoring and phasing in of best practices.
Sure, you could phase in the introduction of an ORM, initially using it for accessing some subset of your domain model. And yes, I have found that use of an ORM speeds up development time - this is one of the key benefits and I certainly don't miss the days when I used to laboriously hand-craft data access layers.
Downsides of ORM - from experience, there is inevitably a bit of a learning curve in getting to grips with the concepts, configuration and idiosyncracies of the chosen ORM solution.
Edit: corrected author's name
The "Robert C Martin" book, which was actually written by Michael Feathers ("Uncle Bob" is, it seems, a brand name these days!) is a must.
It's near-impossible - not to mention insanely time-consuming - to put unit tests into an application not developed with them. The code just won't be amenable.
But that's not a problem. Refactoring is about changing design without changing function (I hope I haven't corrupted the meaning too badly there) so you can work in a much broader fashion.
Start out with big chunks. Set up a repeatable execution, and capture what happens as the expected result for subsequent executions. Now you have your app, or part of it at least, under test. Not a very good or comprehensive test, sure, but it's a start and things can only get better from there.
Now you can start to refactor. You want to start extracting your data access code so that it can be replaced with ORM functionality without disturbing too much. Test often: with legacy apps you'll be surprised what breaks; cohesion and coupling are seldom what they might be.
I'd also consider looking at Martin Fowler's Refactoring, which is, obviously enough, the definitive work on the process.
I work on a large ASP.net application where we recently started to use NHibernate. We moved a large number of domain objects that we had been persisting manually to Sql Server over to NHibernate instead. It simplified things quite a bit and made it much easier to change things over time. We're glad we made the changes and are using NHibernate where appropriate for a lot of our new work.
I heard that TypeMock is often being used to refactor legacy code.
I seriously think introducing ORM into a legacy application is calling for trouble (and might be the same amount of trouble as a complete rewrite).
Other than that, ORM is a great way to go, and should definitely by considered.
The rule for refactoring is. Do unit tests.
So maybe first you should place some unittests at least for the core/major things.
The ORM should be designed for decreasing boilerplate code. The time/trouble vs. ROI to be enterprisy is up to you to estimate :)
Unless your code is already architectured to allow for "hot swapping" of your model layer backend, changing it in any way will always be extremely risky.
Trying to build a safety net of unit tests on poorly architected code isn't going to guarantee success, only make you feel safer about changing it.
So, unless you have a strong business case for taking on the risks involved it's probably best to leave well enough alone.