So what: 'native' DataSet, LINQ to SQL or Entity Framework?
-
Linq to Sql just isn't ready and anything MS puts a Framework tag line on I avoid.
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:
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
-
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 it's best trying to avoid LINQ to SQL for any new development. MS have pretty much abandoned it and if what I've heard is true are giving that reason for not fixing the bugs that exist in it. I haven't used entity framework but guess that's more future proof. Alternatively consider something like nHibernate. I haven't used any other than a teensy bit of L2SQL as our company has its own in-house framework and code generator.
-
Write your own, you will be so much happier with the results. The only framework I recommend using is .NET; everything else is buggy, barely usable, fluff.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
If you don't ask questions the answers won't stand in your way.
Most of this sig is for Google, not ego.Ennis Ray Lynch, Jr. wrote:
The only framework I recommend using is .NET; everything else is buggy, barely usable, fluff.
Hey, now: there's plenty of buggy, barely-usable fluff in .NET...
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
-
Ennis Ray Lynch, Jr. wrote:
The only framework I recommend using is .NET; everything else is buggy, barely usable, fluff.
Hey, now: there's plenty of buggy, barely-usable fluff in .NET...
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
Yes but it only gets worse as you move up the chain not better.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
If you don't ask questions the answers won't stand in your way.
Most of this sig is for Google, not ego. -
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 have yet to experience the apparent value of any ORM, or 'upper' DAL. I'm often more than happy to use the DAAB and pass my UI DataSets from it, if I even need it.
-
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?
LINQ 2 SQL is up in the air at the moment. That said though, I still use it although it makes sense to keep your datalayer flexible enough that it could be repleaced in the future if there is a need. I kind of expect LINQ 2 SQL to stay around, but you never know with Microsoft and their new cuts. I still do not use EF at all, maybe some day but not yet.
Rocky <>< Recent Blog Post: Doughboy – R.I.P. Thinking about Silverlight? www.SilverlightCity.com
-
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