So what: 'native' DataSet, LINQ to SQL or Entity Framework?
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
I think Linq to SQL is a brilliant start if you want to get something up and running fast. Combined with Linqpad to generate queries, cut and paste into C#. Also built into Visual Studio no mucking around with configuration files 3rd party libraries etc etc. Give Linqpad a go for a taste of Linq to SQL. David
-
Ed K wrote:
Linq to Sql just isn't ready
I don't buy that. StackOverflow is becoming one of the biggest dev sites on the web, and they're using Linq-to-SQL behind the scenes.
Ed K wrote:
anything MS puts a Framework tag line on I avoid.
Well then, you should certainly avoid Entities since it's part of the larger .NET framework. :)
Tech, life, family, faith: Give me a visit. The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
I don't buy that.
You don't have to. I'm not trying to sell anything. I was using Linq-to-SQL in a previous project after using Castle.ActiveRecord on several beforehand and comparing the two.. IMHO... Linq-to-SQL just isn't ready for prime time.
Judah Himango wrote:
you should certainly avoid Entities
MS decided to build a testing framework, a logging framework, sql framework and pretty soon I'm expecting a framework framework. They're generally too intrusive, not very flexible and don't cover all the bases. Linq-to-SQL isn't named a framework but same applies.
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
None of the above. I roll my own. Don't relinquish control to some unknown entity (I tried not to use that word, but found no suitable alternative). Use the lowest-level tools you can and retain control of the process. Higher-level frameworks are just bloat that call the same stuff you could be. Anyone who accesses data with .net should have an understanding of the classes in System.Data and should know how to use them. If you then choose to use something else, at least do it as an informed choice.
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
ActiveRecord is so fucking good... you can use the .NET implementation (the castle, but to me is too ugly) or you can use the ruby one! maybe you should take a look in the original Ruby implementation and the working code in Ruby on Rails (so beatyful)... you dont gonna waist your time :) regards from brazil
modified on Wednesday, January 28, 2009 1:42 AM
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
Give SubSonic (www.subsonicproject.com) a bash - the learning curve is fairly flat - it offers a query tool (no sql to write), and a decent code generator. It does force you to stick to an ActiveRecord pattern (1 class per table) but it saves yonks of time. You can modify the code generated through templates. SubSonic is also quite performant . If you fancy bleeding edge code try the new version as this offers some LINQ goodness.
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
We've used LINQ to SQL in a couple of projects. The only problems we've have with it are with the design surface: 1. You can't refresh the entities on the surface from the database unless you delete and re-add them. 2. There's no way to find a specific entity on the design surface. Makes doing item 1 very irritating. Apart from these two irritations, we've found LINQ to SQL very easy to work with. There are plenty of events you can hook into and it's easy to add business logic to the entities as almost everything is declared partial. It certainly beats our previous methods of accessing data for ease of use. Not sure what we'd do with new projects now. I'd have concerns about the ongoing support for LINQ to SQL.
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
Hi, people. I saw a lot of texts and concluded that there is no trust in L2SQL and EF. But what about another tool: TierDeveloper da Alachisoft. That becomes a free software and generate DALs. Some one knows about that?
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
I've worked with Hibernate before and it was great for something small, but found it hard to work with for large object graphs. Also, you really had to design your database a certain way in order for it to work. I've implemented a DAL based on this design http://www.c-sharpcorner.com/UploadFile/rmcochran/elegant_dal05212006130957PM/elegant_dal.aspx[^] and am really happy with it. Code is easy, the repetitive busy work is done for you, and you have full control.
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
We have an Web/click once application with about 50 tables using SQLServer and we use iBatis.net and SpringFramework.net.
Jay Springfield, IL
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
http://www.entityspaces.net That's what I use
-
Judah Himango wrote:
I don't buy that.
You don't have to. I'm not trying to sell anything. I was using Linq-to-SQL in a previous project after using Castle.ActiveRecord on several beforehand and comparing the two.. IMHO... Linq-to-SQL just isn't ready for prime time.
Judah Himango wrote:
you should certainly avoid Entities
MS decided to build a testing framework, a logging framework, sql framework and pretty soon I'm expecting a framework framework. They're generally too intrusive, not very flexible and don't cover all the bases. Linq-to-SQL isn't named a framework but same applies.
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
Ed K wrote:
I was using Linq-to-SQL in a previous project after using Castle.ActiveRecord on several beforehand and comparing the two.. IMHO... Linq-to-SQL just isn't ready for prime time.
I think Linq-to-SQL isn't nearly as comprehensive as Castle AR, from what I understand, perhaps wasn't intended to be. I don't believe that translates into "not ready for use". We disagree.
Tech, life, family, faith: Give me a visit. The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
We use Microsoft's Data Access Application Block, it's simpler than straight ado.net, and in our case most of our calls are to stored procedures which makes the implementation straight forward and efficient.
-
None of the above?
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
An unhelpful comment. Read the quote in your own comment and try to follow it.
'Howard
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
Here's some real-world experience rather than just opinions. I migrated by app from a home-brew datalayer to LINQ-to-SQL (L2S) last year. It's fast and very easy to use once you've built the layer. I am glad I made the jump despite the problems I've had. In doing so I have to overcome several obstacles. The biggest current issue is (as others say) that Microsoft isn't committing to L2S[^] (thanks MS, for launching a technology you then deprecate 12 months later). Implementation wise there are lots of rough edges to development with L2S. The model you create isn't easily updated if you change tables or relationships - there are 3rd party tools out there that can help with this. Security There is no real concept of security in L2S so you have to do this yourself or implement at the database level if possible. Database There are also issues with the depth of SQL support in L2S - for example there is no capability to query an XML field in any way whatsoever, and no way to extend it to do this. You have to write in-line SQL. Another biggie is the L2S is pretty much tied to SQL 2000/2005 and offers no support for anything else. It works with SQL 2008 but cannot access 2008's new types and features. Entities The new MS data mantra is LINQ to Entities (L2E) so if you want to follow this route you would probably be advised to - but who knows if MS will change direction again? In addition L2E has a lot more overhead in design terms and things that are simple in L2S take a bit more work in L2E. On the positive side L2E supports different DB platforms not just MS-SQL, and L2E will also support REST queries (useful if you're using MVC or Silverlight for example). DataSet Don't even go there. Everything is much more complicated and slow than either L2S or L2E.
'Howard
-
I spent the last two days reading various articles and blogs about LINQ to SQL and the Entity Framework. After all, I'm still unsure which technology I should use for a project with a SQL Server 2005/2008 that has 50 or less tables. Any idea?
I used Entity Framework with ADO.Net Data Services for WebService portion of a WPF app I was writting. I liked enough that I scrapped some earlier work I had been doing and re-wrote it use Entity Framework. I usually find that stuff like this works so well for 90% of what you do and the other 10% is near impossible. I have found the 10% part yet.
-
An unhelpful comment. Read the quote in your own comment and try to follow it.
'Howard
On the contrary, it was full of meaning and right on target merely more brief than some of the other replies. As I've said repeatedly prepackaged ORM schemes of any kind lead to shitty software and nothing beats a highly tuned app specific manually created data layer and business object layer. LINQ is a horrible technology that was stillborn, is of no benefit to the end user, which is after all the whole *point* of making software and should be the key for judging any technology. Perhaps if you thought about it first before you replied... ;)
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
-
On the contrary, it was full of meaning and right on target merely more brief than some of the other replies. As I've said repeatedly prepackaged ORM schemes of any kind lead to shitty software and nothing beats a highly tuned app specific manually created data layer and business object layer. LINQ is a horrible technology that was stillborn, is of no benefit to the end user, which is after all the whole *point* of making software and should be the key for judging any technology. Perhaps if you thought about it first before you replied... ;)
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
So in what way did it suggest an alternative? Or are you an advocate of embedded SQL statements built using string concatenation?
'Howard