Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Over the last few months I’ve been concentrating on the new Entity Framework versions, but from now on I’ve to build a complete new .net 3.5 application.
I found out it’s impossible to use the new EF 4.1 in a .net 3.5 application. But seeing the criticism on the first EF version and the out-of-development status of Linq-to-Sql, what is the best way to go on this date?
What arguments should be used in a choice? Thanks in advance!!
As always, the best place to start is by writing down what you need it to do, and then you have a basis to evaluate the myriad of data-access tools available. Don’t get side-tracked by YAGNI features – focus on what you actually need.
The decision itself is subjective; there are die-hards on all sides. Personally I mix’n’match – I’m happy to use LINQ-to-SQL for editing data etc, and dapper-dot-net for read-only displays (it is faster). I’m not anti-EF, but I haven’t found I’ve needed to make that complexity step. Remember; the more complex the ORM/data-access, the more time you need to get it working, and the more reluctant you’ll be to ever change it. Which is why I like low-impact, low-complexity data-access that I can rip out and swap easily.